- HEADER Browserverhalten bei 204 und 205

[Raik]

Hallo,

Das habe ich versucht:
Header('HTTP/1.0 204 No Content');
Header('HTTP/1.0 205 Reset Content');
Getestet habe ich mit IE6 und Firefox 0.9.2.
Auf den Header 204 reagieren die beiden zumindest richtig, soweit ich das verstanden habe: sie machen nach dem absenden des formulars überhaupt nichts (die geladene Seite bleibt stehen).
Wärend der IE6 auf den Header 205 mit dem neu Laden der Seite aus dem Cache reagiert (scheint mir), statt nur die formularfelder zurückzusetzen, macht der Firefox bei meinen Versuchen überhaupt nix.
Frage 1
Ist die Schreibweise so richtig und evtl. eine andere empfehlenswerter?
Frage 2
habe ich die RFC richtig verstanden, dass in beiden Fällen die Seite nicht neu geladen werden soll?
Frage 3
Reagieren andere Browser ähnlich "falsch" auf den Header 205?
frage 4
Wo finde ich evtl. ausfühliche Erklärungen zu allen Headern für Greenhorns möglichst in deutsch?
Die RFC hält sich da doch ziemlich zurück.

freundl. Grüsse aus Berlin, Raik

[Christoph Schnauß]

hallo Raik,

Wo finde ich evtl. ausfühliche Erklärungen zu allen Headern für Greenhorns möglichst in deutsch?

Tststs ... Zwar nicht so sehr zu "Headern", aber zu den Statuscodes, die du als Zahl hintendranschreibst, empfiehlt sich natürlich SELFHTML. Wenn du speziell etwas über die Header wissen willst, ist zufälligerweise in SELFHTML einiges für Perl beschrieben.

Mit welcher Technik willst du denn diese Angaben realisieren, wo schreibst du das hin?

Die RFC hält sich da doch ziemlich zurück.

I wo. http://www.w3.org/Protocols/rfc2616/rfc2616.txt ist doch so ausführlich, wie man es sich nur wünschen kann.

Grüße aus Berlin

Christoph S.

[wahsaga]

hi,

Tststs ... Zwar nicht so sehr zu "Headern", aber zu den Statuscodes, die du als Zahl hintendranschreibst, empfiehlt sich natürlich SELFHTML.

OK, damit dürfte auch schnell klar sein, dass 205 vermutlich nicht der status code ist, den Raik sucht. (sofern die angaben von selfhtml korrekt sind.)

gruß,
wahsaga

[Raik]

Hallo, wahsaga!

OK, damit dürfte auch schnell klar sein, dass 205 vermutlich nicht der status code ist, den Raik sucht. (sofern die angaben von selfhtml korrekt sind.)

diese angaben sind in diesem fall offensichtlich falsch. soviel englisch kann ich noch, dass ich das in der rfc verstanden habe. ;-)

freundl. Grüsse aus Berlin, Raik

[wahsaga]

hi,

diese angaben sind in diesem fall offensichtlich falsch. soviel englisch kann ich noch, dass ich das in der rfc verstanden habe. ;-)

ja stimmt - hätte mir auch auffallen sollen, wo ich es doch eben noch zitiert habe.

gruß,
wahsaga

[Christoph Schnauß]

hi,

OK, damit dürfte auch schnell klar sein, dass 205 vermutlich nicht der status code ist, den Raik sucht. (sofern die angaben von selfhtml korrekt sind.)
diese angaben sind in diesem fall offensichtlich falsch. soviel englisch kann ich noch, dass ich das in der rfc verstanden habe. ;-)

Na prima. So weit ich sehe, hat Stefan die RFC nicht übersetzt, sondern "nacherzählt". Und da ich mich für den SELFHTML-Relaunch auf Version 8.1 gerade für diese Angaben nen bissel verantwortlich fühle (die Seite wird im Gesamtkonzept auch an eine andere Stelle verschoben), bin ich für diese Anmerkung sehr dankbar, bisher habe ich Stefans Tabelle nämlich noch nie wirklich Wort für Wort nachgelesen und an der RFC verglichen. Das werde ih nun doch noch für SELFHTML 8.1 machen dürfen.

Grüße aus Berlin

Christoph S.

[Henryk Plötz]

Moin,

Tststs ... Zwar nicht so sehr zu "Headern", aber zu den Statuscodes, die du als Zahl hintendranschreibst, empfiehlt sich natürlich SELFHTML.

Also eigentlich ... ist das genau die falsche Quelle. Die Angaben zu HTTP-Status-Codes in Selfhtml waren zu einem erschreckend großen Teil schlichtweg falsch oder mindestens ungenau. Was genau kannst du sicher im svn-Log nachlesen, aber ich glaube ich habe mindestens 5 davon korrigieren müssen.

[Christoph Schnauß]

hallo Henryk,

Die Angaben zu HTTP-Status-Codes in Selfhtml waren zu einem erschreckend großen Teil schlichtweg falsch oder mindestens ungenau. Was genau kannst du sicher im svn-Log nachlesen, aber ich glaube ich habe mindestens 5 davon korrigieren müssen.

Mir war an einigen Stellen etwas unwohl, ja, aber ich habe bis heute nie _genau_ verglichen. Macht nichts. Ich werde mir das jetzt nochmal wirklich Wort für Wort vornehmen.

Grüße aus der Nachbarschaft

Christoph S.

[wahsaga]

hi,

Das habe ich versucht:
Header('HTTP/1.0 204 No Content');
Header('HTTP/1.0 205 Reset Content');
Getestet habe ich mit IE6 und Firefox 0.9.2.
Auf den Header 204 reagieren die beiden zumindest richtig, soweit ich das verstanden habe: sie machen nach dem absenden des formulars überhaupt nichts (die geladene Seite bleibt stehen).

jepp, korrekt.

"If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent."
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)

Wärend der IE6 auf den Header 205 mit dem neu Laden der Seite aus dem Cache reagiert (scheint mir), statt nur die formularfelder zurückzusetzen, macht der Firefox bei meinen Versuchen überhaupt nix.

"205 Reset Content
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action."

die formularfelder zu löschen ist also die korrekte aktion.
darüber, ob dies beispielsweise durch erneutes rendern der gecachten version des dokumentes passieren darf, finde ich dort nichts. würde also das verhalten des IEs als erlaubt bezeichnen.

das der firefox gar nichts macht, würde ich als fehler in der implementation deuten.

Frage 1
Ist die Schreibweise so richtig und evtl. eine andere empfehlenswerter?

sofern du folgendes beachtet hast:

"The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields."
bzw. bei 205: "The response MUST NOT include an entity."

Frage 2
habe ich die RFC richtig verstanden, dass in beiden Fällen die Seite nicht neu geladen werden soll?

ja.
das holen und neu rendern der gecacheten version würde ich dabei ggf. noch als korrekt ansehen. obwohl, wenn ich genauer darüber nachdenke  - wenn du jetzt beispielsweise schon per DOM weitere objekte ins dokument eingefügt hättest, würden diese auch wieder verloren gehen ... dann wäre "If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent" evtl. doch eher so zu deuten, dass der browser in _exakt_ der ansicht bleiben sollte, die zum zeitpunkt des requests auch vorhanden war. aus dem cache holen wäre dann kontraproduktiv.

Frage 3
Reagieren andere Browser ähnlich "falsch" auf den Header 205?

k.A. - ausprobieren :-)

wofür beabsichtigst du dieses verhalten denn überhaupt zu nutzen?

frage 4
Wo finde ich evtl. ausfühliche Erklärungen zu allen Headern für Greenhorns möglichst in deutsch?

hmm, RFC 2616, abschnitt 10 auf deutsch zu finden, ist mir auf die schnelle auch nicht gelungen.

gruß,
wahsaga

[Raik]

Hallo, wahsaga!

vielen dank für deine antwort. :-)

wofür beabsichtigst du dieses verhalten denn überhaupt zu nutzen?

ich baue gerade an einem webfrontend für < http://bom.sourceforge.net/@titel=Biet-O-Matic>.
dabei werden Daten an eine Datenbank geschickt, aus der das Programm sich diese dann holt, und sie nach Request an xBay vervollständigt wieder zurückschreibt.
und da der offiziell nicht existierende Header('Refresh: 15;url=http://www.example.com'); anscheinend von den gängigen Browsern verstanden wird, wollte ich die neue Seite verspätet laden, so dass die dann vervollständigten Datensätze erscheinen.

freundl. Grüsse aus Berlin, Raik