Vraag Wat heeft het voor zin om 'www' in een URL te plaatsen?


Anders dan om historische redenen, is er reden om 'www' in een URL te plaatsen?

Moet ik een permanente omleiding van maken www.xyz.com naar xyz.comof van xyz.com naar www.xyz.com? Welke zou je voorstellen en waarom?


223
2018-05-27 08:02


oorsprong


Verwant: stackoverflow.com/questions/1109356/... - Quintin Par
Omgekeerd, wat is het punt in niet. Voor cookies en subdomeindoeleinden op een succesvolle aanwezigheid op het web, is het handig om verschillende processen te scheiden. - Fiasco Labs
Dit antwoord, hoewel niet direct gerelateerd, lijkt relevant. - Skippy le Grand Gourou


antwoorden:


Een van de redenen waarom je nodig hebt www of een ander subdomein heeft te maken met een eigenaardigheid van DNS en de CNAME-record.

Stel dat u in het kader van dit voorbeeld een grote site beheert en hosting uitbesteedt aan een CDN (Content Distribution Network) zoals Akamai. Wat u meestal doet, is het DNS-record voor uw site instellen als een CNAME voor sommigen akamai.com adres. Dit geeft de CDN de mogelijkheid om een ​​IP-adres op te geven dat dicht bij de browser staat (in geografische of netwerktermen). Als u een A-record op uw site gebruikte, zou u deze flexibiliteit niet kunnen bieden.

Het eigenaardigheid van de DNS is dat als je een CNAME-record voor een hostnaam hebt, je dit niet kunt hebben een ander records voor diezelfde host. Uw hoofddomein echter example.com moet meestal een NS- en SOA-record hebben. Daarom kunt u ook geen CNAME-record toevoegen example.com.

Het gebruik van www.example.com geeft je de mogelijkheid om een ​​CNAME te gebruiken voor www die naar uw CDN wijst, terwijl de vereiste NS- en SOA-records worden aangehouden example.com. De example.com record heeft meestal ook een A-record om naar een host te verwijzen waarnaar wordt omgeleid www.example.com een HTTP-omleiding gebruiken.


193
2018-05-27 08:10



U kunt een "standaard" CNAME-record opgeven dat verwijst naar het CDN, u hoeft "www" niet te gebruiken. Hierdoor kan uw DNS-server SOA, NS, CNAME, enz. RR's hebben allemaal voor dezelfde domeinnaam. - Chris S
Hoe komt het dat niemand de ALIAS (of ANAME records) in dit soort onderwerp? Krijgt het niet dezelfde resultaten als de CNAME op nakeddomain (behalve van het probleem met de cookie ...)? - Augustin Riedinger
@AugustinRiedinger: ANAME-records zijn geen standaard DNS RR-type. Ze zijn eigendom van specifieke serviceproviders. - Greg Hewgill
Maar genereert dit compatibiliteitsproblemen of zoiets? Is er een reden waarom we ze niet zouden moeten gebruiken (naast het feit dat ze niet standaard maar propriëtair zijn)? - Augustin Riedinger
@AugustinRiedinger het wordt niet ondersteund op de meeste DNS servers. Maar als je leverancier heeft een DNS-server die deze functies ondersteunt, dan zou dat geen problemen met de clients moeten opleveren. - Koen.


Opmerking: vanaf de ratificatie en implementatie (door alle huidige browsers, behalve mogelijk MSIE 11, zie opmerkingen) van RFC 6265 in 2011 is het volgende niet meer juist, omdat cookies standaard nooit over subdomeinen worden geplaatst.

historisch gezien, een goede technische reden om te maken www.example.com canoniek was dat cookies van een hoofddomein (d.w.z. example.com) zijn verzonden naar alle subdomeinen.

Dus als uw site cookies zou gebruiken, zouden ze naar al haar subdomeinen worden verzonden.

Nu is dit vaak logisch, maar het is zeker schadelijk als je alleen maar statische bronnen wilt downloaden omdat het gewoon de bandbreedte verspilt. Overweeg alle stijlpagina's en afbeeldingen op uw website: meestal is er geen reden om cookies naar de server te sturen bij het aanvragen van een beeldresource.

Een goede oplossing is daarom om een ​​subdomein te gebruiken voor statische bronnen, zoals static.example.com, om bandbreedte te besparen door geen cookies te verzenden. Alle afbeeldingen en andere statische downloads kunnen vanaf daar worden gedownload. Als je nu gebruikt www.example.com voor de dynamische inhoud betekent dit dat cookies alleen moeten worden verzonden naar www.example.com, niet om static.example.com.

Indien echter example.com is uw hoofdsite, dan worden cookies verzonden naar allemaal subdomeinen, inclusief static.example.com.

Nu is dit niet relevant voor de meeste sites, maar het later wijzigen van je canonieke URL is geen goed idee, dus als je eenmaal hebt gekozen voor example.com in plaats van www.*, je zit er feitelijk mee vast.

Een alternatief is om een ​​te gebruiken heel anders URL voor statische bronnen. Stack Overflow maakt bijvoorbeeld gebruik van sstatic.net, YouTube gebruikt ytimg.com enz. …


99
2018-05-27 08:15



Trouwens, ik hou echt niet van www.x als de canonieke URL dus persoonlijk zou ik waarschijnlijk een andere URL gebruiken voor statische bronnen als ik een grote site zou ontwerpen. - Konrad Rudolph
@RobinWinslow Maar met koken wordt ingeschakeld domain=example.com zal de cookie instellen op het apex-domein en op subdomeinen, en een manier om dit te voorkomen is door het apex-domein niet voor HTTP te gebruiken. Hoewel overeengekomen, zou een andere manier zijn om gewoon niet te specificeren domain bij het instellen van de cookie. Ik vraag me af of dit is veranderd sinds ik mijn antwoord schreef (dat dateert van vóór het relevante RFC 6265!) maar ik kan niet de moeite nemen om het nu op te zoeken. - Konrad Rudolph
Het lijkt erop dat het gedrag dat ik beschrijf het geval is sinds ten minste 2011 toen RFC 6265 werd geschreven (meer als een samenvatting van het huidige browser-gedrag dan een verklaring van hoe ze zouden moeten werken). Inmiddels kunnen we aannemen dat alle browsers het zullen volgen. Zien stackoverflow.com/questions/1062963/... en bayou.io/draft/cookie.domain.html. Gezien dit, denk ik dat je antwoord al minstens 7 jaar misleidend is, hoewel het zou kunnen hebben in sommige gevallen correct was op het moment van schrijven. Zou je dit kunnen bijwerken om dit feit te verduidelijken? - Robin Winslow
@RobinWinslow Ja, zal doen. - Konrad Rudolph
@KonradRudolph eigenlijk, volgens mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains, het ongewenste gedrag dat u hebt beschreven, heeft mogelijk bestaan ​​in IE11 op het moment dat het bericht werd geschreven, en mogelijk nog steeds - wat de meest recente versie van Internet Explorer blijft. Dat zou behoorlijk belangrijk en vermeldenswaardig zijn, maar het zou goed zijn om het eerst te controleren. Ik kan het niet gemakkelijk controleren, want ik ben op Ubuntu, maar als je dat zou kunnen zou dat geweldig zijn. - Robin Winslow


www is een subdomein dat gewoonlijk wordt gebruikt voor de webserver op een domein samen met anderen voor andere doeleinden zoals mail etc. Tegenwoordig is het subdomein-paradigma niet nodig; als u verbinding maakt met een website in een browser, krijgt u de website, of stuurt e-mail naar de server zijn e-mailservice.

Gebruik makend van www of niet is een kwestie van persoonlijke voorkeur. Tegengestelde standpunten zijn te vinden op http://no-www.org/ en http://www.yes-www.org/ - Ik geloof dat echter www is onnodig en voegt gewoon meer cruft toe aan de URI.

De meeste servers verzenden dezelfde site in beide gevallen, maar leiden niet door. Voor SEO-doeleinden, kies er een uit en laat de andere daarnaar verwijzen. Bijvoorbeeld een PHP-code om dit te doen:

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

Er zijn echter enkele redenen om het gebruik van een www subdomeinen gemaakt door andere antwoordapparaten zijn ook geweldig, zoals het niet verzenden van cookies naar statische servers (tegoed Konrad Rudolph).


10
2018-05-27 08:11



Lijkt op no-www.org is teruggekeerd naar een geparkeerde geparkeerde pagina waar yes-www.org gaat nog steeds sterk. Ik veronderstel dat het dit doet. Iedereen gebruikt vanaf nu "www". - hacksalot


Als u subdomeinen voor andere doeleinden wilt hebben (bijvoorbeeld een blog), wilt u misschien de sites differentiëren en een www voorvoegsel voor de gewone site. Anders dan dat, is het enige belangrijke ding om een ​​van de twee te kiezen en eraan te houden (vanwege SEO-redenen).


7
2018-05-27 08:06



Ik kan op dit moment geen referentie vinden, maar het kan ook gevolgen hebben voor hetzelfde oorsprongsbeleid. - Kobi
Ja dat zal het helaas doen. Je kunt AJAX niet aan www.example.comvan example.com of vice versa zonder iets als JSONP. - Delan Azabani


Het is behoorlijk historisch. Er was eens een tijd dat we www.example.com, ftp.example.com, images.example.com, uk.example.com enz. Hadden, wat logisch leek en een eenvoudige methode was om de belasting te spreiden tussen servers.

Tegenwoordig zou ik gewoon voor example.com gaan voor de hoofdsite en de www-versie daarnaar verwijzen.

De Met de Webmasterhulpprogramma's van Google kunt u uw voorkeursdomein opgeven, dus zorg ervoor dat je die ook gebruikt.

Zie ook:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to-www-or-not-to-www


7
2018-05-27 08:11





Ik zou de eerste doen. De www conventie komt uit de begintijd van HTTP waarbij www.cmu.edu en cmu.edu zeer waarschijnlijk verschillende machines waren.


6
2018-05-27 08:08



in de 'vroege dagen' zou je zelden een A-record voor een domein zien - misschien zou het een MX-record hebben, maar had je daar zelden een host. - Joe H.


Hier is nog een minder belangrijk perspectief.

Door geen www te hebben, is er een klein minpuntje als het gaat om op tekst gebaseerde media, hetzij gedrukt of online, en dat het wordt herkend als een webadres. In gedrukte vorm is het meestal vrij duidelijk dat example.com een ​​webadres is, en je kunt stijlelementen toevoegen om dat te benadrukken. Maar platte tekst online? Niet zo makkelijk. De kans is groot dat als u een eenvoudig sms-bericht verzendt - e-mail, tweet, Facebook-bericht, sms of wat dan ook - het een URL zal herkennen die begint met http: // of www. maar zal er geen herkennen zonder een van deze. Dus om van de URL een klikbare link te maken, moet u www plaatsen. of http: // op de voorkant en van de twee, www. is korter, minder onhandig om naar te kijken en gemakkelijker te lezen.


1
2017-11-24 18:22



http://example.com/ is volledig gekwalificeerd terwijl www.example.com is niet. Ik geef de voorkeur aan de volledig gekwalificeerde aanpak omdat het zo is altijd herkenbaar als een URL, ongeacht of het is https://example.uk/ of https://blog.example.eu/ of wat dan ook. Het is consistent met het specificeren van het protocol van een beveiligde site als HTTPS; www.example.com is gewoon een domein en zegt niets over welk protocol men moet gebruiken om er toegang toe te hebben. - James Haigh