tweakers.net. onbekende host?

[Verwijderd]

Het bezoeken van tweakers.net. (let op de laatste punt, achter net) gaat sinds vanmiddag niet meer.
De laatste punt is optioneel onderdeel van een hostname, en geeft volgens mij de root aan. Dat bijna niemand het in typt, is natuurlijk logisch, maar om de correcte(re) hostname niet ondersteunen is raar.

Hoe komt het dat het zo werkt? Apache zal die hostnames toch wel zelf goed snappen? Is er soms een nieuw PHP-scriptje dat de hostname als string gebruikt oid?

[Glaanie]

Gerelateerd aan pw.tweakers.net is niet meer :( ? Ik denk dat een aantal config files zijn aangepast cq verwijderd vanwege de verwijdering van de core, pro en life channels, die nu rubrieken zijn geworden en nu geen subdomein meer hebben, maar gewoon een subfolder.

[burne]

Verwijderd schreef op maandag 07 juli 2008 @ 19:07:
Het bezoeken van tweakers.net. (let op de laatste punt, achter net) gaat sinds vanmiddag niet meer.

(ns-verhaal was onzin, iets te snel gedacht..)

http://tweakers.net./ bedoel je?

[ Voor 46% gewijzigd door burne op 07-07-2008 20:50 ]

[moto-moi]

Ik kan het zo 1-2-3 niet terugvinden in http://tools.ietf.org/html/rfc1945 of http://tools.ietf.org/html/rfc2616 ?

[Oid]

En de pw.tweakers.net waarom is die weggehaald ik gebruikte dat echt supervaak, zouden jullie dat terug kunnen halen.

[Glaanie]

Thijmen schreef op maandag 07 juli 2008 @ 21:31:
En de pw.tweakers.net waarom is die weggehaald ik gebruikte dat echt supervaak, zouden jullie dat terug kunnen halen.

pw.tweakers.net is niet meer :(

[blaataaps]

moto-moi schreef op maandag 07 juli 2008 @ 21:19:
Ik kan het zo 1-2-3 niet terugvinden in http://tools.ietf.org/html/rfc1945 of http://tools.ietf.org/html/rfc2616 ?

Waarom zou een verhaal over de DNS-hierarchie dan ook in de rfc's over http staan?

[r0b]

Ik kwam het volgende tegen wat dit beschrijft: http://homepages.tesco.ne...ualified-domain-name.html
Nu moet ik zeggen dat het in de genoemde RFC's vrij onduidelijk staat,

quote: http://www.ietf.org/rfc/rfc2396.txt

The rightmost domain label of a fully qualified domain name will never
start with a digit, thus syntactically distinguishing domain names from IPv4 addresses,
and may be followed by a single "." if it is necessary to distinguish between the complete domain name and any local domain.

To actually be "Uniform" as a resource locator, a URL hostname should be a fully qualified domain name.
In practice, however, the host component may be a local domain literal.

[Verwijderd]

Apache volgt die RFC's sowieso niet 100% vanwege IDN support, voor zover ik weet. Zie static void fix_hostname(request_rec *r) in server/vhost.c

[Osiris]

Grappig, als ik naar m'n eigen Apache "surf" met telnet en een domein *met* trailing dot in de Host-header zet, dan krijg ik gewoon die site te zien? Ipv een geen-site-op-dit-adres-melding die je wel krijgt bij een niet-bestaande vhost.

Hmm, trailing dot komt niet in $_SERVER["SERVER_NAME"] van PHP te staan.

[ Voor 17% gewijzigd door Osiris op 07-07-2008 21:54 ]

[moto-moi]

blaataaps schreef op maandag 07 juli 2008 @ 21:35:
Waarom zou een verhaal over de DNS-hierarchie dan ook in de rfc's over http staan?

Daarom geef ik die voorbeelden ook, ik wist niet dat het een dns 'feature' was

[crisp]

trailing dot komt dus wel in $_SERVER['HTTP_HOST'] en we doen tegenwoordig strictere host-checking. Ik zal 'm aanpassen mbt de trailing dot.

[Osiris]

Ah, ik zat vrij verkeerd te kijken inderdaad, my bad.

[Verwijderd]

we doen tegenwoordig strictere host-checking

Waarom zou je dat willen checken? Dat is toch de rol van Apache en niet van een webapplicatie?

[Verwijderd]

Verwijderd schreef op dinsdag 08 juli 2008 @ 03:38:

Waarom zou je dat willen checken? Dat is toch de rol van Apache en niet van een webapplicatie?

Waarom? Je kunt toch heel makkelijk willen dat dezelfde applicatie achter verschillende hostnames hangt? Sterker nog, dat bij een onbekende hostname de standaard vhost wordt gebruikt om de request af te handelen?

Op zo'n manier heb ik samen met een collega eens een systeem gemaakt waarbij nu zo'n 100 websites op exact dezelfde software draaien. De persoon die onderhoud pleegt kan er on the fly nieuwe "websites" bij maken, zonder Apache te hoeven herconfigureren.

Ik denk dat mensen te gauw iets aan Apache overlaten, hetzelfde zie je steeds bij mod_rewrite en dat soort zaken. Soms is het veel handiger zulke dingen op applicatieniveau te doen.

[crisp]

Het is inderdaad omdat we gewoon voor al onze domeinen de standaard vhost willen gebruiken en vervolgens wat meer controle willen hebben over de afhandeling op basis van hostname. Zo redirect http://tweakers.me.uk bijvoorbeeld naar de meuktracker en http://tweakgear.nl naar de tweakgear shop.

Echter betekend een catch-all vhost ook dat je allemaal bogus requests krijgt te verwerken. Zo kregen we dagelijks duizenden requests binnen voor o.a. host baidu.com, en dat is een potentieel security risico - immers als we rucksightloss cookies zouden zetten op basis van host dan zijn die uiteindelijk door de echte baidu.com website uit te lezen.

[Glaanie]

crisp schreef op dinsdag 08 juli 2008 @ 09:02:
Het is inderdaad omdat we gewoon voor al onze domeinen de standaard vhost willen gebruiken en vervolgens wat meer controle willen hebben over de afhandeling op basis van hostname. Zo redirect http://tweakers.me.uk bijvoorbeeld naar de meuktracker en http://tweakgear.nl naar de tweakgear shop.

Echter betekend een catch-all vhost ook dat je allemaal bogus requests krijgt te verwerken. Zo kregen we dagelijks duizenden requests binnen voor o.a. host baidu.com, en dat is een potentieel security risico - immers als we rucksightloss cookies zouden zetten op basis van host dan zijn die uiteindelijk door de echte baidu.com website uit te lezen.

offtopic:
tweakers.me.uk? Lol Zijn er nog meer 'vreemde' (dus niet *.tweakers.net/nl) domeinen die leuk zijn om te vermelden?