In che modo i siti Web dovrebbero gestire il nome host con punto finale?

Ho letto questa domanda Come possono gli URL avere un punto. alla fine, ad es. www.bla.de.? e rendersi conto che il nome di dominio completo deve contenere un trailing .per l'etichetta radice dell'albero DNS:

example.com. invece di example.com

Tuttavia, ci sono problemi come sottolineato in questo articolo del blog :

Se non consideri il fatto che l'utente può inserire accidentalmente il nome di dominio con un punto alla fine o seguire un collegamento ricevuto da un "pozzo" e ottenere il tuo nome di dominio con il punto alla fine, come il risultato può portare a conseguenze inattese:

1) Se il sito Web utilizza HTTPS, durante la navigazione verso il nome di dominio con il punto alla fine, il browser visualizzerà l'avviso su una connessione non attendibile.

2) L'autenticazione può essere interrotta, poiché i cookie vengono generalmente impostati per il nome di dominio senza un punto alla fine. L'utente in questo caso sarà piuttosto sorpreso dal motivo per cui non può accedere. È interessante notare che se si imposta un cookie per un nome di dominio con un punto alla fine, questo cookie non verrà passato al nome di dominio senza il punto alla fine e viceversa.

3) JavaScript nella pagina potrebbe essere rotto.

4) Potrebbero esserci problemi con la memorizzazione nella cache delle pagine del sito Web (ad esempio, https://www.cloudflare.com/non cancella la cache delle pagine se il nome di dominio ha un punto alla fine considerandolo un nome di dominio non valido).

5) Se nelle condizioni nella configurazione del web server ti affidi al particolare nome di dominio ($ http_host in Nginx,% {HTTP_HOST} in Apache) senza il punto alla fine, potresti dover affrontare una varietà di situazioni impreviste: reindirizzamenti imprevisti, base problemi di autorizzazione, ecc.

6) Se il server Web non è configurato per accettare richieste sul nome di dominio con il punto finale, qualsiasi utente che abbia digitato accidentalmente un nome di dominio con il punto finale vedrà qualcosa come Richiesta errata - Nome host non valido.

7) È possibile che i motori di ricerca trovino che la tua risorsa ha un contenuto duplicato, se qualcuno pubblica accidentalmente o intenzionalmente collegamenti alle tue pagine web con un punto alla fine del nome di dominio.

Mi rendo anche conto che http://webmasters.stackexchange.com./fa a 400 Bad Request. Ma poiché il nome di dominio vero e proprio dovrebbe contenere un .alla fine, non dovremmo emettere 400errori o 301reindirizzare i nomi host senza un punto finale? Qual è il modo corretto di affrontare questo problema in modo coerente e coerente?

Per rispondere parzialmente alla tua domanda, puoi aggiungerla alle regole di inoltro canonico htaccess. In un senso HTTP di base, cerca un periodo prima dell'URI e funziona in qualunque meccanismo di inoltro anti-duplicato che usi. Ecco un esempio che include una route sub-util "dominio addon" comune:

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/$1" [R=301,L]

Ciò che farebbe è inoltrare tutto quanto segue a un dominio www canonico HTTP:

• domain.hostdomain.com
• domain.hostdomain.com.
• www.domain.hostdomain.com
• www.domain.hostdomain.com.
• domain.com
• domain.com.
• www.domain.com.

Tutti inoltrano a:

• http://www.domain.com

C'è però un avvertimento : come affermato nella citazione originale del blog, SSL non inoltrerà correttamente e genererà un avviso del browser o 400 errori di richiesta errata nella maggior parte delle istanze del server (specialmente con HSTS). Questo perché vede l'SSL "host" in un caso d'uso post-TLD. Non sono sicuro di una soluzione alternativa per gestire l'avviso SSL host poiché viene prima di htaccess e cose.

Mi piace pensare al punto finale come la "vera" radice di Internet e che vive in Virginia, negli Stati Uniti. Se lasci il punto, allora viene sempre implicata una radice. Per gli utenti normali, è la stessa radice, ed è la situazione che discuterò oggi.

Nel mio modo perverso, trovo davvero il punto finale abbastanza utile. Se sto visitando il sito Web di qualcun altro e voglio ricominciare da capo, senza cache, senza cookie, ecc., E sono troppo pigro per svuotare quelli, userò un browser diverso o aggiungerò il punto. Se il sito non mi reindirizza, ho URL completamente nuovi non memorizzati nella cache per tutte le pagine del sito e altre risorse.

Come webmaster, desidero che tutte le persone e i robot che visualizzano una pagina la visualizzino con lo stesso URL e quindi con lo stesso nome host. Se il nome host non è quello che voglio che usino, farò un reindirizzamento immediato 301 in modo che vedano l'URL corretto nel loro browser. Per i miei siti basati su PHP, gestisco il problema in PHP e non nel file .htaccess o web.config, poiché è più portatile ed è più facile da testare su server di sviluppo e gestione temporanea. Gestisco le mie connessioni al database allo stesso tempo, poiché variano anche tra server di sviluppo / gestione temporanea / produzione.

Ecco una versione semplificata del mio codice tipico. Nota i reindirizzamenti canonici verso la fine.

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
                break;
        case 'www.exampleweb.com':                  // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
                break;
        case 'exampleweb.mystagingsite.net':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
                break;
        case 'exampleweb.com':                  // canonical redirects 
        case 'exampleweb.com.':
        case 'www.exampleweb.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.exampleweb.com");
                exit;
        default:
                die("invalid hostname $Host");
    }   

il mio commento su https://core.trac.wordpress.org/ticket/35248#comment:9 :

la mia risposta al testo con il primo link ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Originariamente, come definito in RFC 1738 (§ 3.1), la parte "host" di un URL (Common Internet Scheme) era sempre e inequivocabilmente un nome di dominio pienamente qualificato e il meccanismo convenzionale per distinguere i nomi di dominio pienamente qualificati da quelli non completamente nomi di dominio qualificati non applicati. Se fosse example.com. o example.com, l'host doveva essere lo stesso.

- Penso che non abbia ragione, penso che "example.com" non sia stato affatto ammesso negli URL secondo RFC 1738, è citato nel secondo testo, e lo cito:

3.1. Sintassi comune dello schema Internet
        // <utente>: <password> @ <host>: <porta> / <url-path>
    ospite
        Il nome di dominio completo di un host di rete

e "example.com" non poteva essere usato nelle intestazioni http in quel momento, perché rfc 1738 è del 1994 e il campo host è apparso solo con http 1.1 nel 1997 (puoi controllare su Wikipedia).

quindi, in effetti, negli URL è stato lasciato solo fqdn. penso che questo sia stato un errore nell'RFC 1738, perché in tal modo ha reso (provato a rendere) la funzione "domini relativi" inutile. se non lo impediva, teoricamente potrebbero essere usati in "a" tag hrefs in siti locali con script o documentazione html statica all'interno di grandi aziende che utilizzavano domini relativi, se i browser e i server lo supportavano. ma anche se rfc 1738 non lo consentiva, le persone non lo obbedivano: continuavano a usare domini di primo livello in forma relativa, cioè senza punto finale, quindi questo divieto da rfc 1738 non era comunque un grosso problema pratico e la gente aveva e usava un'alternativa a domini relativi: hanno appena creato domini di primo livello locali come "localhost" (e li hanno usati e utilizzati anche senza punto finale).

poi dice:

Sfortunatamente, in pratica i browser Web hanno sempre violato tale specifica e passato la parte "host" attraverso le procedure di qualificazione del nome delle loro librerie Client DNS durante la mappatura del nome host su un set di indirizzi IP. (Ad esempio, quelli che utilizzavano la libreria client DNS BIND lascerebbero impostata l'opzione RES_DNSRCH e non aggiungerebbero il punto finale finale se mancava.)

- penso che intendesse dire che gli host senza punto finale devono essere semplicemente eliminati come errore e che solo i domini assoluti (fqdn) dovrebbero essere passati a dns. penso che probabilmente i browser abbiano passato tutti i domini al DNS perché le persone usavano i loro domini di primo livello locali personalizzati come "localhost". e comunque, successivamente nell'RFC 2396 pubblicato nel 1998, fu consentito l'uso di domini di primo livello negli URL senza punti finali.

quindi l'autore (Jonathan de Boyne Pollard) cita rfc 2396 e si rammarica per il fatto che sia cambiato in base al comportamento umano stabilito, vale a dire gli standard di fatto, dice che sarebbe meglio se i browser obbedissero a rfc 1738, e raccomanda a tutte le persone di usare solo fqdn, in tutti i posti, come era comandato da rfc 1738.

- ma cosa succederebbe se le persone obbedissero a rfc 1738? url come "http://example.com/test.html "e"http: //localhost/test.html "tutti dovevano essere riscritti come"http://example.com./test.html "e"http://localhost./test.html". Il browser dovrebbe contrassegnare gli host senza punti come errore o reindirizzare facendo clic su di essi in modo completo / assoluto. Tutte le persone che hanno configurato domini locali di livello superiore come" localhost "dovrebbero configurare i propri server per accettare solo richieste per domini come "localhost", oppure accetta e reindirizza [tutti gli URL all'interno] "localhost" a [URL corrispondenti in] "localhost". Il testo come "localhost" rimarrebbe utile solo quando lo digiti nella barra degli indirizzi del browser, ma che sarebbe solo un uso molto inutile, e la relativa funzione di dominio non è necessaria per questo, perché i browser cercano domini durante la digitazione. L'uso di essi in sorgente html diventerebbe inutile perché porterebbe a che tali collegamenti non funzionerebbero, o facendo clic su tutto i collegamenti con "localhost" sposteranno l'utente a "localhost."e sarebbe solo un ulteriore reindirizzamento su ogni clic (su tali collegamenti). Pertanto, rfc 1738 renderebbe completamente inutile la funzionalità di" dominio relativo "pianificata. Se qualche azienda utilizzasse tale funzionalità e utilizzasse i propri domini relativi nei propri siti locali, e i loro URL con domini relativi non venivano reindirizzati in forma assoluta dai browser, quindi i loro siti funzionavano normalmente, se obbedivano anche a rfc 1736, avrebbero configurato i loro server per accettare solo fqdn e avrebbero dovuto riscrivere tutti questi URL con fqdn, o lavorare con reindirizzamento extra su ogni clic su tali URL. se a quelle aziende piaceva avere un dominio breve come "team101" invece di "team101.microsoft.com" nelle barre degli indirizzi e nelle fonti html, avrebbero dovuto iniziare a utilizzare i loro domini di primo livello interni personalizzati come "team101." ovvero "localhost. "invece di sottodomini come" team101.microsoft.com. "(che potrebbe essere utilizzato solo come" team101 "prima che decidessero di obbedire a rfc 1738).

-

e ho scoperto che il punto finale, che è stato così fortemente supportato da rfc 1738, è apparso davvero solo dopo lo standart senza punti finali! è apparso con rfc 1034 nel 1987, è citato nel secondo link e lo cito:

Poiché un nome di dominio completo termina con l'etichetta radice, questo porta a
forma stampata che termina in un punto. Usiamo questa proprietà per distinguere tra:
- una stringa di caratteri che rappresenta un nome di dominio completo
 (spesso chiamato "assoluto"). Ad esempio, "poneria.ISI.EDU."
- una stringa di caratteri che rappresenta le etichette iniziali di a
 nome di dominio che è incompleto e deve essere completato da
 software locale che utilizza la conoscenza del dominio locale (spesso
 chiamato "relativo"). Ad esempio, "poneria" utilizzato in
 Dominio ISI.EDU.

rfc 1034 (del 1987) ha appena dichiarato tutti i domini utilizzati, sembra che tutti fossero senza punti finali, li ha dichiarati tutti come domini relativi! ma funzionavano ancora come prima, quindi probabilmente poche persone lo sapevano e continuavano a pensare che stavano chiedendo inequivocabilmente un sito "esempio.com" reale unico quando usano "esempio.com" senza punto finale. così in alcuni casi è diventata un'ulteriore violazione della sicurezza: il famoso esempio reale reale potrebbe essere falsificato da un amministratore di sottodominio anche se non gli fosse stato concesso il diritto di creare domini locali come "localhost". così, anche rfc 1034 non è stato progettato molto bene: sembra che i suoi autori non si aspettassero che forse sarà {non molto conosciuto, quindi creando una violazione della sicurezza}!

probabilmente rfc 1738 (1994) ha infine tentato di portare l'idea della distinzione tra domini assoluti e relativi a un vasto pubblico e ha anche risolto tale violazione della sicurezza dopo 6 anni, {ma risolvendo la violazione della sicurezza, impedendo domini relativi negli URL, ha reso inutili i domini relativi , {ma penso che probabilmente non siano stati ampiamente utilizzati, probabilmente solo in alcune grandi aziende}}. quindi, quale sarebbe [lasciato] in seguito a RFC 1737, se fosse obbedito? - 1) i domini relativi dichiarati nel 1987 diventerebbero infine inutili, quindi, il punto finale, progettato per mostrare il dominio assoluto, diventerebbe infine inutilmente e ridondante "legalmente", cioè come definito dagli RFC! (ma forse hanno pianificato in seguito di autorizzare nuovamente i domini relativi negli URL dopo molti anni, quando un vasto pubblico (il pubblico in generale) inizia a conoscere la possibilità di domini relativi). 2) e rfc 1737, se fosse stato rispettato, avrebbe anche risolto la violazione della sicurezza. - ma anche rfc 1034 non creerebbe la violazione della sicurezza se raggiungesse le masse ed è stato ampiamente compreso che l'uso del dominio relativo non è sicuro! - Quindi, la ricetta principale per risolverlo stava raggiungendo il vasto pubblico e pubblicare un altro rfc era solo uno dei molti modi per farlo.

penso ora che probabilmente la funzione relativa al dominio non sia diventata ampiamente nota dopo l'RFC 1034 (del 1987) perché era di uso troppo limitato: solo in alcune grandi aziende o reti locali dei fornitori, ed era una funzione senza valore pratico, poiché le reti locali potevano già creare qualsiasi dominio locale, quindi quella funzione era solo per se stessa, in realtà era solo un testo inutile in rfc che chiunque dovrebbe conoscere e utilizzare senza avere alcun vantaggio aggiuntivo! ma le persone hanno creato la piccola violazione della sicurezza ignorando ampiamente l'RFC, mentre i browser hanno iniziato a obbedire.

ieri ho verificato la relativa funzione dei domini, funziona. (va bene, perché l'RFC 2396 (del 1998) lo ha permesso nuovamente dopo l'RFC 1034 (del 1987) negato, e successivamente l'RFC 3986 (del 2005) glielo consente ancora). ho aggiunto il suffisso DNS in Windows 10 - pannello di controllo - ... - proprietà del dispositivo di rete - proprietà ipv4 - aggiuntivo - scheda dns. quando ho aggiunto "google.com" quindi ho aperto "http: // mail / "in firefox, ha aperto il server di google, ma non è stato configurato per funzionare solo con" mail "nell'intestazione" host "http, quindi ho ottenuto qualcosa come la pagina" 404 ".

-

la mia risposta al testo con il secondo link ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

cita anche la regola nell'RFC 1738 e dice:

Sfortunatamente, le persone che implementavano i client del browser web sembravano non capire cosa significasse. Quando si accede a un sito Web, il valore che la maggior parte dei browser Web inserisce nel campo "Host:" è ciò che l'utente ha digitato, non quello che il computer ha effettivamente utilizzato, dopo aver applicato l'elenco di ricerca dell'utente DNS per creare un nome completo dal nome parziale. Ad esempio, qui ci sono tre modi diversi in cui l'utente può fare riferimento all'host "www.esempio.com". ... Quando si invia il parametro "Host:" al server Web, il client del browser Web inserisce invece ciò che l'utente ha digitato ("www.example.com.", "Www.example.com" o "www") di ciò che il client ha effettivamente cercato nel DNS ("www.example.com." in tutti e tre i casi). ...

- questo non è molto vero (corretto), perché rfc 1738 era molto severo in questo senso, e non consentiva domini relativi in ​​tutti gli URL, anche se si trova nella barra degli indirizzi del browser, e l'URL stesso è il modo [raccomandato] di fare qualsiasi riferimento a siti, anche se le persone lo scrivono su carta, quindi non era permesso agli utenti di fare riferimento a quel sito in quel 3 modi, a partire da rfc 1738, se quegli utenti pensavano che usavano l'URL!

e sembra che l'autore di questo testo (Stuart Cheshire) non fosse a conoscenza dell'RFC 2396, quindi questo testo non è aggiornato.

-

e qual è la situazione al giorno d'oggi? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) consente di fare riferimento al dominio assoluto senza punto finale: dice "L'etichetta di dominio più a destra di un nome di dominio completo in DNS può essere seguita da un singolo". "" e che dovrebbe essere usato se è "necessario distinguere tra il nome di dominio completo e un dominio locale". penso che a causa degli standard di fatto non sia quasi mai necessario, quindi wordpress può accettare lo standard di fatto e reindirizzare dall'indirizzo con punto finale all'indirizzo senza di esso.