[Allegro] Re: [allegro-OEB] open/get mit http://-URL

[Michael Lackhoff]

Lieber Herr Berger,

>> Ich bin uebrigens ebenfalls der Meinung wie Herr Berger, dass naemlich
>> die 30x Statuscodes einen Sinn haben, auf den man nicht ohne Not
>> verzichten sollte. Ihr Anliegen kann ich zwar auch nachvollziehen, es
> 
> pardon, das ist aber nicht meine Meinung: Gerade bei HTTP 1.1. *haben*
> die Statuscodes bereits eine *Bedeutung*. Und auf die kann man nicht
> "verzichten", man kann nur gegen das Protokoll verstossen, indem man eine
> andere Bedeutung unterschiebt: Immerhin sind ja alle "Agents" (HTTP-Klienten)
> verpflichtet,  sich der in der Spezifikation festgelegten Bedeutung
> entsprechend zu verhalten, sonst wuerden die ganzen Statuscodes keinen "Sinn"
> machen.

Nun ja, man kann sich natuerlich ueber die genaue Bedeutung der
Spezifikation[1] streiten:
If the 301 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the request
unless it can be confirmed by the user, since this might change the
conditions under which the request was issued.
(ansonsten steht im RFC nur etwas darueber, was der Server machen soll,
nicht, wie der user agent darauf reagieren soll)

Ich lese daraus nur, dass es bei GET nicht verboten ist, dem redirect
automatisch zu folgen, nicht aber, dass es verpflichtend ist.
Natuerlich ist es in vielen Faellen sinnvoll dem redirect (bei den nicht
schreibenden Verben) zu folgen.
Und natuerlich kann der Statuscode nicht seine Bedeutung verlieren ("die
Resource liegt jetzt woanders und zwar da und da") man hat aber meiner
Meinung nach sehr wohl die Freiheit dem gegebenen Hinweis nicht zu
folgen. Vielleicht kann man es so zusammenfassen: 301 ist ein Hinweis
und kein Befehl. Sonst waeren alle user agents, die es erlauben,
redirects nicht zu folgen (z.B. wget, curl, die erwaehnte MFC-Funktion)
spezifikationswidrig, was ich nicht erkennen kann.

Viele Gruesse
Michael Lackhoff

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2