Qual è il punto di avere "www" in un URL?

238

Oltre a motivi storici, c'è motivo di avere "www" in un URL?

Devo creare un reindirizzamento permanente da www.xyz.coma xyz.como da xyz.coma www.xyz.com? Quale consiglieresti e perché?

http url redirect

— Quintin Par
fonte

2

Correlati: stackoverflow.com/questions/1109356/…

— Quintin Par

Al contrario, qual è il punto in no. Ai fini di cookie e sottodomini su una presenza Web di successo, è utile separare diversi processi.

— Fiasco Labs,

Questa risposta , sebbene non direttamente correlata, sembra pertinente.

— Skippy le Grand Gourou,

202

Uno dei motivi per cui hai bisogno wwwo qualche altro sottodominio ha a che fare con una stranezza di DNS e il record CNAME.

Supponiamo che ai fini di questo esempio si stia eseguendo un sito di grandi dimensioni e si contenga l'hosting a una rete CDN (Content Distribution Network) come Akamai. Quello che fai di solito è impostare il record DNS per il tuo sito come CNAME su un akamai.comindirizzo. Ciò offre alla CDN la possibilità di fornire un indirizzo IP vicino al browser (in termini geografici o di rete). Se hai utilizzato un record A sul tuo sito, non saresti in grado di offrire questa flessibilità.

La stranezza del DNS è che se si dispone di un record CNAME per un nome host, non è possibile avere altri record per quello stesso host. Tuttavia, il dominio di primo livello example.comdeve in genere avere un record NS e SOA. Pertanto, non è possibile aggiungere anche un record CNAME per example.com.

L'uso di www.example.comti dà l'opportunità di usare un CNAME per wwwquel punto sulla tua CDN, lasciando i record NS e SOA richiesti example.com. Il example.comrecord di solito avrà anche un record A che punta a un host che reindirizzerà www.example.comall'utilizzo di un reindirizzamento HTTP.

— Greg Hewgill
fonte

3

Puoi fornire un record CNAME "predefinito" che punta alla CDN, non è necessario utilizzare "www". Ciò consente al server DNS di disporre di RR SOA, NS, CNAME, ecc. Tutti per lo stesso nome di dominio.

— Chris S,

1

Come mai nessuno menziona il ALIAS(o il ANAMErecord) in questo tipo di argomento? Non ottiene gli stessi risultati del CNAME su nakeddomain (tranne per il problema dei cookie ...)?

— Augustin Riedinger,

3

@AugustinRiedinger: i record ANAME non sono un tipo RR DNS standard. Sono proprietari di fornitori di servizi specifici.

— Greg Hewgill,

Ma questo genera problemi di compatibilità o qualcosa del genere? C'è qualche motivo per cui non dovremmo usarli (oltre a non essere standard ma proprietari)?

— Augustin Riedinger,

2

@AugustinRiedinger non è supportato sulla maggior parte dei server DNS . Ma se il tuo provider ha un server DNS che supporta queste funzionalità, ciò non dovrebbe dare problemi ai client.

— Koen.

104

Nota: a partire dalla ratifica e dall'implementazione (da parte di tutti i browser attuali, tranne eventualmente MSIE 11 , vedere i commenti) di RFC 6265 nel 2011, quanto segue non è più accurato, poiché i cookie per impostazione predefinita non sono mai impostati su sottodomini.

Storicamente , un buon motivo tecnico per rendere www.example.comcanonico era che i cookie di un dominio principale (cioè example.com) venivano inviati a tutti i sottodomini.

Quindi, se il tuo sito utilizzava i cookie, sarebbero inviati a tutti i suoi sottodomini.

Ora, questo ha spesso senso, ma è positivamente dannoso se si desidera scaricare solo risorse statiche poiché spreca solo larghezza di banda. Prendi in considerazione tutti i fogli di stile e le immagini sul tuo sito Web: di solito, non c'è motivo di inviare cookie al server quando si richiede una risorsa di immagine.

Una buona soluzione è quindi quella di utilizzare un sottodominio per risorse statiche, ad esempio static.example.com, per risparmiare larghezza di banda evitando l'invio di cookie. Tutte le immagini e altri download statici possono essere scaricati da lì. Se ora utilizzi www.example.comper il contenuto dinamico, ciò significa che i cookie devono essere inviati solo a www.example.com, non a static.example.com.

Se, tuttavia, example.comè il tuo sito principale, i cookie verranno inviati a tutti i sottodomini, incluso static.example.com.

Ora questo non è rilevante per la maggior parte dei siti, ma cambiare l'URL canonico in seguito non è una buona idea, quindi una volta che ti sei accontentato example.cominvece di www.*, sei praticamente bloccato con esso.

Un'alternativa è utilizzare un URL completamente diverso per le risorse statiche. Stack Overflow ad esempio utilizza sstatic.net, utilizza YouTube ytimg.comecc ...

— Konrad Rudolph
fonte

11

A proposito, non mi piace davvero www.xcome l'URL canonico, quindi personalmente probabilmente userei un URL diverso per le risorse statiche se dovessi progettare un grande sito.

— Konrad Rudolph,

1

@RobinWinslow Ma impostando cookes domain=example.comsi imposta il cookie sul dominio apex e sui sottodomini , e un modo per evitarlo è di non utilizzare il dominio apex per HTTP. Tuttavia, concordato, un altro modo sarebbe semplicemente non specificare domainquando si imposta il cookie. Mi chiedo se questo sia cambiato da quando ho scritto la mia risposta (che precede il pertinente RFC 6265 !), Ma non posso preoccuparmi di cercarlo ora.

— Konrad Rudolph,

2

Sembra che il comportamento che descrivo sia stato il caso almeno dal 2011, quando è stato scritto RFC 6265 (più come una sintesi del comportamento attuale del browser che una dichiarazione su come dovrebbero funzionare). Ormai, possiamo presumere che tutti i browser lo seguiranno. Vedere stackoverflow.com/questions/1062963/... e bayou.io/draft/cookie.domain.html . Detto questo, penso che la tua risposta sia stata fuorviante per almeno 7 anni, anche se in alcuni casi avrebbe potuto essere accurata al momento della stesura. Potresti aggiornarlo per chiarire questo fatto?

— Robin Winslow,

2

@RobinWinslow Sì, lo farà.

— Konrad Rudolph,

2

Altre prove che IE11 fa la cosa cattiva: developer.microsoft.com/en-us/microsoft-edge/platform/issues/…

— Robin Winslow,

12

wwwè un sottodominio solitamente utilizzato per il server Web su un dominio insieme ad altri per altri scopi come mailecc. Oggi il paradigma del sottodominio non è necessario; se ti connetti a un sito Web in un browser, otterrai il sito Web o l'invio di posta al server utilizzerà il suo servizio di posta.

L'uso wwwo meno è una questione di preferenza personale. Punti di vista opposti si possono trovare su http://no-www.org/ e http://www.yes-www.org/ - tuttavia, ritengo che ciò wwwnon sia necessario e aggiunge semplicemente più cruft all'URI.

La maggior parte dei server invia lo stesso sito in entrambi i modi, ma non reindirizza. Ai fini SEO, scegline uno, quindi chiedi all'altro di reindirizzarlo. Ad esempio, alcuni codici PHP per fare ciò:

if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
  header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
  exit;
}

Tuttavia, alcuni motivi che promuovono l'uso di un wwwsottodominio creato da altri risponditori sono altrettanto importanti, come non inviare cookie a server statici (credito Konrad Rudolph ).

— Delan Azabani
fonte

2

Sembra che no-www.org sia tornato a una pagina parcheggiata in vendita dove yes-www.org sta ancora andando forte. Immagino che lo risolva. Tutti usano "www" da ora in poi.

— nunya,

9

È piuttosto storico. Una volta avevamo www.example.com, ftp.example.com, images.example.com, uk.example.com ecc. Che sembravano una cosa logica da fare e fornivano un metodo semplice per distribuire il carico tra server.

In questi giorni vorrei andare ad esempio.com per il sito principale e reindirizzare la versione www a quello.

Gli strumenti per i Webmaster di Google ti consentono di specificare il tuo dominio preferito , quindi assicurati di utilizzare anche quelli.

Vedi anche:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to- www-o-non-a-www

— Comunità
fonte

8

Se hai dei sottodomini per altri scopi (blog per esempio), potresti voler differenziare i siti e avere un wwwprefisso per il sito normale. Oltre a ciò, l'unica cosa importante è scegliere uno dei due e attenersi ad esso (per motivi SEO).

— Oded
fonte

1

Non riesco a trovare riferimenti al momento, ma potrebbe anche avere effetti sulla stessa politica di origine.

— Kobi,

Sì, sfortunatamente. Non puoi AJAX www.example.comda example.como viceversa senza qualcosa come JSONP.

— Delan Azabani,

7

Farei il primo. La wwwconvenzione viene dai primi giorni di HTTP, dove www.cmu.edu e cmu.edu erano probabilmente macchine diverse.

— rifiuti solidi urbani
fonte

10

nei primi tempi vedevi raramente un record A per un dominio - forse avrebbe avuto un record MX, ma raramente avevi un host lì.

— Joe H.

2

Ecco un'altra prospettiva minore.

Non avendo www, c'è un piccolo svantaggio quando si tratta di media basati su testo, sia stampati che online, e che viene riconosciuto come un indirizzo web. Nella stampa, di solito è abbastanza ovvio che example.com è un indirizzo web e puoi aggiungere tocchi di stile per evidenziarlo. Ma semplice testo online? Non così semplice. È probabile che se invii un messaggio di testo semplice, sia esso email, tweet, post di Facebook, SMS o altro, riconoscerà un URL che inizia con http: // o www. ma non riconoscerà uno senza nessuno di questi. Quindi, per trasformare l'URL in un link cliccabile, devi inserire www. o http: // sul davanti, e dei due, www. è più corto, meno goffo da guardare e più facile da leggere.

— raggio
fonte

2

http://example.com/è pienamente qualificato, mentre www.example.comnon lo è. Preferisco l'approccio completo perché è sempre riconoscibile come URL indipendentemente dal fatto che https://example.uk/sia https://blog.example.eu/o meno. È coerente con la specifica del protocollo di un sito sicuro come HTTPS; www.example.comè solo un dominio e non dice nulla su quale protocollo si dovrebbe usare per accedervi.

— James Haigh,