HTTP Statuscodes in Theorie und Praxis am Beispiel von Freenet

Peter Schuller Fails

Ich bin heute über eine interessante Verwendungsweise der HTTP Statuscodes gestolpert. Diese sind ja im Rahmen des HTTP Standards RFC 2616 auch standardisiert worden.

Fragt also jemand eine Ressource an, die von der angefragten URL auf eine andere URL verschoben wurde, ist es also legitim mit einem HTTP 301 Moved Permanently zu antworten. Genau das tut Freenet, wenn man eine beliebige Ressource unter http://freenet.de anfragt, weitergeleitet wird zum angefragten Pfad auf dem Server http://www.freenet.de.

$ curl http://freenet.de/whatever -v
> GET /whatever HTTP/1.1
> User-Agent: curl/7.26.0
> Host: freenet.de
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Access-Control-Allow-Origin: http://www.freenet.de
< X-UA-Compatible: IE=edge
< Location: http://www.freenet.de/whatever
< Vary: Accept-Encoding
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 298
< Accept-Ranges: bytes
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.freenet.de/whatever">here</a>.</p>
<hr>
<address>Apache Server at freenet.de Port 80</address>
</body></html>

Soweit so gut. Folgt man der Weiterleitung kommt, soweit auch noch legitim, die nächste Weiterleitung. Diesmal pfadrelativ auf /index.html, wobei aber der GET Parameter notfound mit der angefragten URL belegt wird.

$ curl http://www.freenet.de/whatever -v
> GET /whatever HTTP/1.1
> User-Agent: curl/7.26.0
> Host: www.freenet.de
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Access-Control-Allow-Origin: http://www.freenet.de
< X-UA-Compatible: IE=edge
< Set-Cookie: JSESSIONID=0CCBCF62520AF3397CB4F84F7AD4D633.CAE3TC2; Path=/freenet
/; HttpOnly
< Location: /index.html?notfound=http%253A%252F%252Fwww.freenet.de%252Fwhatever
< Set-Cookie: frn075ucp="{\"profile\":{\"weatherHistory\":[],\"financeHistory\":
[],\"profileData\":{\"ic\":\"\",\"hs\":\"1\",\"wss\":\"622\",\"1\":\"2\",\"ts\":
\"super\",\"c\":\"134-238-220-214-59-94-88-94\",\"bs\":\"ALL\"}}}"; Version=1; D
omain=.md.de; Max-Age=5184000; Expires=Tue, 14-Jul-2015 20:56:09 GMT; Path=/
< Vary: Accept-Encoding
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 0
< Accept-Ranges: bytes
< Connection: keep-alive
<

Das klingt nicht nur komisch, sondern ist es auch, denn es führt wie erwartet auf die Startseite von Freenet, mit dem kleinen Hinweis:

Diese Seite konnte leider nicht gefunden werden.
http://www.freenet.de/whatever
Bitte wählen Sie ein anderes Thema aus diesem Bereich.

Gab es nicht für genau den Zweck mal einen eigenen Statuscode? Ja, da war was, ein kurzer Blick in den RFC 2616, genauer gesagt Abschnitt 10.4.5 fördert folgendes zu Tage:

404 Not Found

The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other
response is applicable.

Richtig, der gute alte 404er...kleiner Praxistipp, wie die Theorie in der Praxis umzusetzen ist, z.B. bei Apache:

ErrorDocument 404 /errors/not_found.html

Mit den Servervariablen kann man dann sogar auf die Anfrage des Nutzers reagieren...

Zugegeben, beim Aufruf mit dem Browser macht das keinen Unterschied, wenn aber ein Client automatisiert einen Link auf der Suche nach einer bestimmten Ressource öffnet wäre der korrekte Statuscode dann doch hilfreich...