[php] hyperlinken controleren op een website

[Gerwin]

Hier ben ik al eens vaker mee bezig geweest, maar het lukt me maar niet om dit juist aan de praat te krijgen, ik heb me helemaal suf zitten zoeken in de Search maar daar kom ik telkens maar weer uit op topics vergelijkbaar met [rml][ php] controleren op broken links[/rml]. Hier kijkt men of het bestandje bestaat op een andere server, maar stel nu dat er een redirect op die pagina is. Dan bestaat die website dus alsnog en krijg je geen foutmelding. Is het mogelijk om een PHP script te maken die kijkt of het bestandje een code OK meekrijgt en mocht deze anders zijn dan de link te markeren in bijvoorbeeld eendatabase... ik doel meet over de manier zoals Checkkit de boel naloopt... Hoe kan ik bijvoorbeeld een header uit de opgevraagde link halen?

[Erkens]

zelf een socket connectie maken en dan de headers uitlezen?

[Verwijderd]

je krijgt in je header een statuscode terug, bij een 404 heb je een dode link te pakken

[Erkens]

Verwijderd schreef op 14 augustus 2003 @ 16:38:
je krijgt in je header een statuscode terug, bij een 404 heb je een dode link te pakken

niet alleen bij 404's
je moet checken op geldige status codes, zoals 200, en redirects, beter is het om die te volgen etc etc

offtopic:
kan je je ondertitel wat inkorten zo verneuk je de layout een beetje

[ Voor 13% gewijzigd door Erkens op 14-08-2003 16:40 ]

[Gerwin]

Verwijderd schreef op 14 augustus 2003 @ 16:38:
je krijgt in je header een statuscode terug, bij een 404 heb je een dode link te pakken

Ok, ik heb nu dit:

PHP:

  $fp = fsockopen("tweakers.net",80);
  fputs($fp,"HEAD / HTTP/1.0\n\n");
    $buffer = fgets($fp,4096);
    echo($buffer);
  fclose($fp);

krijg als output:

code:

HTTP/1.1 200 OK

Maar nu heb ik dus nog niet de redirects ofzo. Ik wil die ook eruit hebben. Dus mocht een bestandje niet bestaan en er word verwezen naar een andere plek op de server dan wil ik die als fout hebben.

Bovendien werkt dit met "lange" urls niet... ik kan bijvoorbeeld geen bestandjes op de server zelf bekijken hiermee.. krijg een error

[Suepahfly]

Waarom niet gewoon

PHP:

<?
if(file_get_content($url)
{
     //link bestaat
}
else
{
     //link is dood
}

?>

[Gerwin]

Heb nu dit scriptje, hiermee zou het mogelijk moeten zijn complete urls te checken...

PHP:

           $var = ""; 
            $file = parse_url("$url"); 
            $fp = fsockopen("$file[host]",80, &$errno, &$errstr, 30); 

            @fputs($fp,"HEAD /$file[path] HTTP/1.0\r\n\r\n"); 
            @fputs($fp,"Host: $file[host]\r\n\r\n"); 

            while(!feof($fp)){ 
              $this[] = @fgets($fp,100); 
            } 

            $j = count($this); 
                for ($i=0; $i<$j; $i++){ 
                        $var .= $this[$i]; 
                        $var .= "<Br>"; 
                } 
            str_replace(" ","<br>", $var); 
            echo "$var";

Maar als ik vervolgens een willekeurige url wil kijken krijg ik vaak een 404 error... terwijl het bestandje gewoon bestaat

[Gerwin]

Suepahfly schreef op 14 August 2003 @ 17:25:
Waarom niet gewoon

PHP:

<?
if(file_get_content($url)
{
     //link bestaat
}
else
{
     //link is dood
}

?>

Omdat ik de redirects en andere rommel er ook uit wil hebben. Het gebeurd nogal eens dat een pagia niet bestaat of een website opgeheven is en men dan de hele zaak gewoon redirect naar een andere website... Dat wil ik voorkomen.

Ik heb een lijst met zo'n 600 links op de site staan die ik eigenlijk dagelijks meerdere keren wil controleren of de url waar ik naar link nog bestaat naar wat er stond toen ik er een link naar geplaatst heb.

[Gerwin]

Gerwin schreef op 14 augustus 2003 @ 17:27:
Heb nu dit scriptje, hiermee zou het mogelijk moeten zijn complete urls te checken...

PHP:

           $var = ""; 
            $file = parse_url("$url"); 
            $fp = fsockopen("$file[host]",80, &$errno, &$errstr, 30); 

            @fputs($fp,"HEAD /$file[path] HTTP/1.0\r\n\r\n"); 
            @fputs($fp,"Host: $file[host]\r\n\r\n"); 

            while(!feof($fp)){ 
              $this[] = @fgets($fp,100); 
            } 

            $j = count($this); 
                for ($i=0; $i<$j; $i++){ 
                        $var .= $this[$i]; 
                        $var .= "<Br>"; 
                } 
            str_replace(" ","<br>", $var); 
            echo "$var";

Maar als ik vervolgens een willekeurige url wil kijken krijg ik vaak een 404 error... terwijl het bestandje gewoon bestaat

Hoe kan het nu als ik met bovenstaande code de website van bijvoorbeeld Nu.nl wil controleren... ik krijg op de volgende urls de daaropvolgende error:

http://www.nu.nl/index.jsp

code:

HTTP/1.0 404 Not Found 
Date: Thu, 14 Aug 2003 15:51:37 GMT 
Server: Apache/1.3.26 (Unix) Debian GNU/Linux 
X-Cache: HIT from celtic 
Content-Type: text/html; charset=iso-8859-1 
Via: 1.0 ics_server.pagina.nl (ICS 2.1.145_SP2)

http://www.nu.nl/

code:

HTTP/1.0 403 Forbidden 
Date: Thu, 14 Aug 2003 15:51:21 GMT 
Server: Apache/1.3.26 (Unix) Debian GNU/Linux 
X-Cache: HIT from celtic 
Content-Type: text/html; charset=iso-8859-1 
Via: 1.0 ics_server.pagina.nl (ICS 2.1.145_SP2)

http://www.nu.nl/rubriek.jsp?n=100&c=10

code:

HTTP/1.0 404 Not Found 
Date: Thu, 14 Aug 2003 15:56:26 GMT 
Server: Apache/1.3.26 (Unix) Debian GNU/Linux 
X-Cache: MISS from choral 
Content-Type: text/html; charset=iso-8859-1 
Content-Length: 206 
Via: 1.0 ics_server.pagina.nl (ICS 2.1.145_SP2)

[ Voor 13% gewijzigd door Gerwin op 14-08-2003 17:56 ]

[Erkens]

Gerwin schreef op 14 August 2003 @ 17:55:
[...]


Hoe kan het nu als ik met bovenstaande code de website van bijvoorbeeld Nu.nl wil controleren... ik krijg op de volgende urls de daaropvolgende error:

waarom onderdruk je eventuele foutmeldingen?
tevens zou je je variabelen niet binnen die quotes kunnen zetten, zeker met array's krijg je daar soms problemen mee.

doe trouwens ook eens een print_r() ofzo voor $file

kortom, ga debuggen

[ Voor 11% gewijzigd door Erkens op 14-08-2003 18:45 ]

[bigtree]

Gerwin schreef op 14 August 2003 @ 17:55:
[...]
Hoe kan het nu als ik met bovenstaande code de website van bijvoorbeeld Nu.nl wil controleren... ik krijg op de volgende urls de daaropvolgende error:

Verander

PHP:

@fputs($fp,"HEAD /$file[path] HTTP/1.0\r\n\r\n");

in

PHP:

@fputs($fp,"HEAD $file[path] HTTP/1.0\r\n\r\n");

[Erkens]

bigtree schreef op 14 August 2003 @ 18:46:
[...]

Verander

PHP:

@fputs($fp,"HEAD /$file[path] HTTP/1.0\r\n\r\n");

in

PHP:

@fputs($fp,"HEAD $file[path] HTTP/1.0\r\n\r\n");

doe het dan zo:

PHP:

fputs($fp,"HEAD ".$file[path]." HTTP/1.0\r\n\r\n");

[Gerwin]

Heb wat aangepast. Me is duidelijk dat als ik een url opvraag met een slash erachter dat ik die dan niet ook nog eens in de head request moet zetten; om te voorkomgen dat ik daar dus een dubbele slash krijg. Echter ik krijg nog wat vage dingen:

http://www.nu.nl

code:

HTTP/1.0 200 OK 
Date: Thu, 14 Aug 2003 16:59:28 GMT 
Server: Apache/1.3.26 (Unix) Debian GNU/Linux 
X-Cache: MISS from celtic 
Content-Type: text/html; charset=iso-8859-1 
Content-Length: 18362 
Via: 1.0 ics_server.pagina.nl (ICS 2.1.145_SP2)

http://www.nu.nl/rubriek.jsp?n=100&c=10

code:

HTTP/1.0 404 Not Found 
Date: Thu, 14 Aug 2003 16:59:59 GMT 
Server: Apache/1.3.26 (Unix) Debian GNU/Linux 
X-Cache: HIT from celtic 
Content-Type: text/html; charset=iso-8859-1 
Via: 1.0 ics_server.pagina.nl (ICS 2.1.145_SP2)

http://frontpage.fok.nl/news.fok?id=31550

code:

HTTP/1.1 302 Found 
Date: Thu, 14 Aug 2003 17:03:08 GMT 
Server: Apache/1.3.27 (Unix) PHP/4.2.3 
X-Powered-By: PHP/4.2.3 
Location: http://frontpage.fok.nl//news.fok 
Connection: close 
Content-Type: text/html; charset=iso-8859-15

Waarom hier 302?

[djluc]

Een andere instelling op de server misschien? Als je nou eens zou gaan zoeken wat die foutmelding betekent kun je het misschien wel bedenken. Staat op www.Apache.org geen overzicht?

[Gerwin]

djluc schreef op 14 August 2003 @ 19:07:
Een andere instelling op de server misschien? Als je nou eens zou gaan zoeken wat die foutmelding betekent kun je het misschien wel bedenken. Staat op www.Apache.org geen overzicht?

Foutmeldingen weet ik wel wat die betekenen. Maar ik vind het vreemd at Fok! geen gewone 200 code geeft, en waarom krijg ik op een willekeurige pagina die gewoon via de browser op te vragen is van nu.nl een 404 (Not Found) error?

[Erkens]

Gerwin schreef op 14 August 2003 @ 19:12:
[...]

Foutmeldingen weet ik wel wat die betekenen. Maar ik vind het vreemd at Fok! geen gewone 200 code geeft, en waarom krijg ik op een willekeurige pagina die gewoon via de browser op te vragen is van nu.nl een 404 (Not Found) error?

echo eens jouw http headers die je verstuurt

[Gerwin]

Erkens schreef op 14 August 2003 @ 19:13:
[...]

echo eens jouw http headers die je verstuurt

In het scriptje dat ik hierboven heb verstuur ik zelf toch geen headers? Ik doe toch gewoon vanuit een php website een request op de FOk! server... er is dus geen cache of what-so-ever. Dus die 302 dat hij hem gevonden heeft is een beetje raar, ofnie?

Daarbij komt: hoe kan het dat ik op een nu nieuwsbericht een 404 error krijg als ik er een head request op de server doe?

[Erkens]

Gerwin schreef op 14 August 2003 @ 19:18:
[...]

In het scriptje dat ik hierboven heb verstuur ik zelf toch geen headers? Ik doe toch gewoon vanuit een php website een request op de FOk! server... er is dus geen cache of what-so-ever. Dus die 302 dat hij hem gevonden heeft is een beetje raar, ofnie?

Daarbij komt: hoe kan het dat ik op een nu nieuwsbericht een 404 error krijg als ik er een head request op de server doe?

ehm natuurlijk stuur je zelf http-headers, anders zou je helemaal geen reactie krijgen

een 404 krijg je als je een niet bestaande file/page opvraagt bij een http server.
Dus wat vraag je op? juist, ga debuggen, dus alles outputten

[Gerwin]

Erkens schreef op 14 August 2003 @ 19:21:
[...]

ehm natuurlijk stuur je zelf http-headers, anders zou je helemaal geen reactie krijgen

een 404 krijg je als je een niet bestaande file/page opvraagt bij een http server.
Dus wat vraag je op? juist, ga debuggen, dus alles outputten

Hoe en wat ik mijn eigen headers kan bekijken die ik naar de server stuur heb ik geen idee van ik doe gewoon de volgende vraag:

PHP:

           $var = ""; 
            $file = parse_url($url); 
            $fp = fsockopen($file[host],80, &$errno, &$errstr, 30); 

            $e = fputs($fp,"HEAD ".$file[path]." HTTP/1.0\r\n\r\n");
            @fputs($fp,"Host: $file[host]\r\n\r\n"); 

            echo $file[path];

            while(!feof($fp)){ 
              $this[] = @fgets($fp,100); 
            } 

            $j = count($this); 
                for ($i=0; $i<$j; $i++){ 
                        $var .= $this[$i]; 
                        $var .= "<Br>"; 
                } 
            str_replace(" ","<br>", $var); 
echo "<BR><BR><BR><HR><BR><BR><BR>";
            echo "$var";

Rare is dat hij nu die nu.nl pagina wel pakt en een 200 code heeft. FOK! geeft nog steeds een 302... niet echt een probleem omdat dit iig geen foutmelding is.

[Verwijderd]

is 302 niet dat de data niet is veranderd?

[Erkens]

Gerwin schreef op 14 August 2003 @ 19:26:
[...]

Hoe en wat ik mijn eigen headers kan bekijken die ik naar de server stuur heb ik geen idee van ik doe gewoon de volgende vraag:

PHP:

            $e = fputs($fp,"HEAD ".$file[path]." HTTP/1.0\r\n\r\n");
            @fputs($fp,"Host: $file[host]\r\n\r\n");

nee idd je stuurt zelf niets naar die server

offtopic:
gebruik nooit een @ om fouten te onderdrukken, en al helemaal niet als je aan het debuggen bent

[Olaf van der Spek]

Als je een netwerk sniffer installeert kun je precies zien wat er gebeurd (als je die PHP code op je eigen systeem uitvoert). Dan zie je waarschijnlijk wel wat er fout gaat (en wat het verschil is met een IE request).

[justmental]

http://www.w3.org/Protoco...fc2616-sec6.html#sec6.1.1

[Olaf van der Spek]

Gerwin schreef op 14 August 2003 @ 19:18:
[...]

In het scriptje dat ik hierboven heb verstuur ik zelf toch geen headers? Ik doe toch gewoon vanuit een php website een request op de FOk! server... er is dus geen cache of what-so-ever. Dus die 302 dat hij hem gevonden heeft is een beetje raar, ofnie?

Daarbij komt: hoe kan het dat ik op een nu nieuwsbericht een 404 error krijg als ik er een head request op de server doe?

Nee, dat is omdat je de Host header fout verstuurd.

[Gerwin]

Verwijderd schreef op 14 August 2003 @ 20:45:
is 302 niet dat de data niet is veranderd?

Dat zou kunnen, maar ik heb toch helemaal nergens een "cache" in het systeem zitten. Hoe kan hij nu zien dat het niet veranderd is?

OlafvdSpek schreef op 14 August 2003 @ 22:41:
[...]

Nee, dat is omdat je de Host header fout verstuurd.

Wat is er dan fout aan, en hoe kan ik aan een dergelijke Sniffit komen? Ik heb een betaalde Virtual Host.

[Sendy]

Is het niet zo dat bij die 302 je verwezen wordt naar de URL in de Location: header? (Lees toch even die URL die justmental geeft.)

[ Voor 22% gewijzigd door Sendy op 14-08-2003 22:56 ]

[Gerwin]

Thuissendy schreef op 14 augustus 2003 @ 22:55:
Is het niet zo dat bij die 302 je verwezen wordt naar de URL in de Location: header?

Een rewrite URL bedoel je? Dat zou kunnen, maar globaal kun je die 302 dus niet als een "echte" url zien toch? Mensen die bijvoorbeeld hun site submitten bij mij en waarnaar ik ze plaats dan moet ik die 302 dus behandelen als: "Mogelijk veranderd"...

[bigtree]

Gerwin schreef op 14 August 2003 @ 19:26:
[...]

Rare is dat hij nu die nu.nl pagina wel pakt en een 200 code heeft. FOK! geeft nog steeds een 302... niet echt een probleem omdat dit iig geen foutmelding is.

Wat er raar aan is, is dat nu.nl eigenlijk een 404 zou moeten sturen. Je vraagt echt de verkeerde pagina op. Wat er precies verkeerd gaat, is te simpel voor woorden om uit te leggen. Verdiep je eerst eens in het http protocol (link is al gegeven), kijk wat $file[query] precies is, en als je er dan nog niet uit komt, trek dan maar weer aan de bel. En bovenal: leer debuggen.

[Gerwin]

bigtree schreef op 14 August 2003 @ 23:06:
[...]

Wat er raar aan is, is dat nu.nl eigenlijk een 404 zou moeten sturen. Je vraagt echt de verkeerde pagina op. Wat er precies verkeerd gaat, is te simpel voor woorden om uit te leggen. Verdiep je eerst eens in het http protocol (link is al gegeven), kijk wat $file[query] precies is, en als je er dan nog niet uit komt, trek dan maar weer aan de bel. En bovenal: leer debuggen.

Waarom moet Nu.nl een 404 error geven op een pagina dat gewoon bestaat?
Ik heb me verdiept in het http protocol, alleen vraag ik me af hoe ik nu 100% zeker kan weten of de pagina ook bestaat. Dus geen redirects of what-so-ever. Ik wil iig niet dat ze "kunnen" cheaten door mij eerst een leuke site te laten zien, waarnaar ik 'm op mijn site zet waarnaar hun er van alles aan veranderen en hem laten redirecten naar een andere site met allemaal rommel. Maar zoals ik het nu lees is zoiets nooit 100% te controleren, men kan altijd een header meesturen dus dat ze een 200 code geven en toch de pagina laten redirecten, of niet?

[Verwijderd]

effe een paar dingetjes,
keys in named arrays ($file[query]) moet je quoten met single quotes, $file[query] moet dus $file['query'] zijn.

een @ voor een functie is fout, je kunt beter zorgen dat je code goed werkt of dat de error wordt afgevangen door een functie.

Dit is ook fout: "Host: $file[host]\r\n\r\n" dit doe je zo:
"Host: {$file['host']}\r\n\r\n"

of zo:
"Host: ".$file['host']."\r\n\r\n"

Het is even wennen om netjes te leren coden, maar sommige php installaties zeuren overal over , en het is natuurlijk heel stout om je niet aan de regels te houden

[bigtree]

Gerwin schreef op 14 August 2003 @ 23:12:
[...]

Waarom moet Nu.nl een 404 error geven op een pagina dat gewoon bestaat?

Omdat dit de pagina is die je opvraagt:

De pagina die u op onze site zocht kan helaas niet gevonden worden.

men kan altijd een header meesturen dus dat ze een 200 code geven en toch de pagina laten redirecten, of niet?

Ja dat kan met een meta-refresh bijvoorbeeld.

[ Voor 22% gewijzigd door bigtree op 14-08-2003 23:20 ]

[pistole]

Gerwin schreef op 14 August 2003 @ 23:12:
[...]
Maar zoals ik het nu lees is zoiets nooit 100% te controleren, men kan altijd een header meesturen dus dat ze een 200 code geven en toch de pagina laten redirecten, of niet?

100% zeker bestaat inderdaad niet. Al zouden ze een pagina neerzetten, dan kan je daar ook weer dmw javascript ergens anders heen redirecten...
Ik zou zeggen: als je echt een zeer belangrijke site aan het maken bent, zet er dan een moderator op die e.e.a. controleert; laat mensen "dead link" (of misbruik) melden, etc etc.

[ Voor 32% gewijzigd door pistole op 14-08-2003 23:21 ]

[drecaise]

ligt het aan mij of kom je gewoon kennis over het http protocol te kort?
in ieder geval: HTTP protocol

[Gerwin]

Verwijderd schreef op 14 August 2003 @ 23:18:
effe een paar dingetjes,
keys in named arrays ($file[query]) moet je quoten met single quotes, $file[query] moet dus $file['query'] zijn.

een @ voor een functie is fout, je kunt beter zorgen dat je code goed werkt of dat de error wordt afgevangen door een functie.

Dit is ook fout: "Host: $file[host]\r\n\r\n" dit doe je zo:
"Host: {$file['host']}\r\n\r\n"

of zo:
"Host: ".$file['host']."\r\n\r\n"

Het is even wennen om netjes te leren coden, maar sommige php installaties zeuren overal over , en het is natuurlijk heel stout om je niet aan de regels te houden

Bedankt voor de feedback, ik ga het verandere.

bigtree schreef op 14 August 2003 @ 23:18:
[...]
Omdat dit de pagina is die je opvraagt:
[...]

[...]
Ja dat kan met een meta-refresh bijvoorbeeld.

Over dat bericht in Nu.nl is al opgelost. Het ging er hier om dat ik met mijn scriptje een nieuwsbericht op Nu.nl opvraag dat gewoon bestaat en dat niet een melding heeft dat de pagina niet bestaat.

Die META refresh kan ik niet zien met die codes inderdaad, maar daar kom ik nog op. Ik wil eerst weten of de pagina wel bestaat, later ga ik dan nog kijken of er bepaalde dingen in de bron van de pagina staat dat ik niet wil hebben, zo kan ik dan kijken of men ergens de boel aan het bedonderen is. Maar ik wil eerst die codes goed in orde hebben

pistole schreef op 14 August 2003 @ 23:19:
[...]

100% zeker bestaat inderdaad niet. Al zouden ze een pagina neerzetten, dan kan je daar ook weer dmw javascript ergens anders heen redirecten...
Ik zou zeggen: als je echt een zeer belangrijke site aan het maken bent, zet er dan een moderator op die e.e.a. controleert; laat mensen "dead link" (of misbruik) melden, etc etc.

Moderator ben ik zelf, maar ik wil niet handmatig meerdere keren per dag alle honderden/duizenden linkjes op de site nalopen. Wil dat geautomatiseerd hebben op de server dmv php ofzo.


Dat zou kunnen, hoewel iik me er wel in verdiept heb, en om nu honderden pagina's door te gaan lezen voor iets heel simpels dat vind ik een beetje te veel van het goede, dan zeg ik: ik lees de functies en dingen die ik nodig heb en gebruik die. Alleen kloppen de response codes dus niet altijd...

[Olaf van der Spek]

Gerwin schreef op 14 August 2003 @ 22:55:
Wat is er dan fout aan, en hoe kan ik aan een dergelijke Sniffit komen? Ik heb een betaalde Virtual Host.

code:

telnet frontpage.fok.nl 80\n
GET /news.fok?id=31550 HTTP/1.0\n
Host: frontpage.fok.nl\n
\n

Dan geeft fok netjes dat nieuwsbericht.
Ethereal kun je vinden op http://ethereal.com/
Je moet dan de PHP code wel lokaal draaien, anders valt er niet veel te sniffen.

[pistole]

ik denk dat de responses goed zullen kloppen mits je de requests goed doet (denk bv ook aan referers, content-types (wat accept je?) etc).
Je zou ook een middenweg kunnen kiezen:
-check je sites/links
-rapporteer alles wat niet correct lijkt (zal niet meer zijn dan een paar % lijkt me)
-controleer handmatig datgene dat niet automatisch lukt, of, indien mogelijk, pas daar je controlemechanisme op aan

[rmfloris]

Nadat het topic een tijdje is stil geweest, toch maar weer een reactie.

Ik heb geprobeerd om dit script aan te passen. Dat is redelijk goed gelukt, maar het lukt het script nog steeds niet controleren of een pagina (.htm, .php etc) aanwezig is.

Dus bijvoorbeeld http://www.leukesmsjes.net/smsjes.php?c=1, deze geeft een 404 terug (http://www.leukesmsjes.net = 200), terwijl andere site zoals webwereld.nl (http://www.webwereld.nl/nieuws/18563.phtml) wel een 200 terug geven.

waar kan dit aan liggen dat de ene server niet werkt en de andere server wel werkt, maar misschien belangrijker, hoe los ik het op.

[Gerwin]

Ik ben nadien ook nog wat bezig geweest maar dit is mij vooralsnog ook nog niet gelukt. Je kunt wel kijken hoe groot het bestandje is maar de response code krijg je niet altijd goed terug. Daarnaast wilde ik ook controleren op de pagina of er code op de pagina staat die ik er liever niet op wil hebben bijvoorbeeld een javascript redirect.

[Shadowman]

Gerwin schreef op 14 augustus 2003 @ 19:26:
[...]

PHP:

            $var = ""; 
            $file = parse_url($url); 
            $fp = fsockopen($file[host],80, &$errno, &$errstr, 30); 

            $e = fputs($fp,"HEAD ".$file[path]." HTTP/1.0\r\n\r\n");
            @fputs($fp,"Host: $file[host]\r\n\r\n");

Volgens mij zit hier het probleem in het feit dat de laatste regel van de header twee maal een \r\n moet hebben en de regels daarvoor dit slechts een keer moeten hebben.

[T.T.]

Hier heb ik toevallig pas een paper over gelezen.

Electronic Document Addressing: Dealing with Change

The management of electronic document collections is fundamentally different from the management of paper documents. The ephemeral nature of some electronic documents means that the document address (i.e., reference details of the document) can become incorrect some time after coming into use, resulting in references, such as index entries and hypertext links, failing to correctly address the document they describe. A classic case of invalidated references is on the World Wide Web—links that point to a named resource fail when the domain name, file name, or any other aspect of the addressed resource is changed, resulting in the well-known Error 404. Additionally, there are other errors which arise from changes to document collections.
This paper surveys the strategies used both in World Wide Web software and other hypertext systems for managing the integrity of references and hence the integrity of links. Some strategies are preventative, not permitting errors to occur; others are corrective, discovering reference errors and sometimes attempting to correct them; while the last strategy is adaptive, because references are calculated on a just-in-time basis, according the current state of the document collection.