content-length:0 bei Keep-Alive?
Christoph Zurnieden
- https
Hallo zusammen,
eigentlich eine selten dämliche Frage meint man, oder?
Aber die RFC 2616 ist, wie fast jede RFC, schwer verständlich und daher oft auch mißverständlich, wiedersprüchlich und ungenau. So auch hier.
HTTP/1.1 geht davon aus, daß jede Verbindung dauerhaft wäre:
8.1.2 Overall Operation
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client
SHOULD assume that the server will maintain a persistent connection,
even after error responses from the server.
[...]
Sowie noch:
8.1.2.1 Negotiation
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including
the connection-token "close" was sent in the request. If the server
chooses to close the connection immediately after sending the
response, it SHOULD send a Connection header including the
connection-token close.
[...]
Der Keep-Alive Header ist demnach eine Beschränkung dieser Dauerhaftigkeit, keine explizite Anforderung von Dauerhaftigkeit.
Nun sagt aber die RFC etwas weiter in 8.1.2.1:
In order to remain persistent, all messages on the connection MUST
have a self-defined message length (i.e., one not defined by closure
of the connection), as described in section 4.4.
Nun ist die Frage: Muß ein GET ohne Body ein Content-Length:0 mitschicken, oder nicht?
(Kurzer Praxistest: Mozilla 1.1 macht es z.B. nicht)
so short
Christoph Zurnieden
Hallo Christoph,
Nun ist die Frage: Muß ein GET ohne Body ein
Content-Length:0 mitschicken, oder nicht?
Laut RFC sollte er, ja. Und logisch ist es auch, sonst muss der
Browser ausprobieren, wann der Body zuende ist. Einzige mir
bekannte Ausnahmen sind '100 Continue' und '101 Switching
Protocols'.
(Kurzer Praxistest: Mozilla 1.1 macht es z.B. nicht)
Ach, du meinst, ob der *Browser* ein Content-Length mitschicken
muss? Noe. GET hat per Definition keinen Body, und ein
Content-Length-Header laesst *immer* auf einen Body
schliessen (steht zumindest so in der RFC).
Gruesse,
CK
Hallo,
Da warst Du aber flott, hatte gedacht, das braucht bestimmt bis morgen, bis da jemand drauf antwortet ;-)
(Kurzer Praxistest: Mozilla 1.1 macht es z.B. nicht)
Ach, du meinst, ob der *Browser* ein Content-Length mitschicken
muss? Noe. GET hat per Definition keinen Body, und ein
Content-Length-Header laesst *immer* auf einen Body
schliessen (steht zumindest so in der RFC).
Ah, das ist ein gutes Argument, dankeschön!
so short
Christoph Zurnieden
Hallo Christoph,
Da warst Du aber flott, hatte gedacht, das braucht bestimmt
bis morgen, bis da jemand drauf antwortet ;-)
Nee, nicht bei so interessanten Themen :)
Wofuer brauchst du das eigentlich? Schreibelst du an 'nem
Browser 'rum?
Gruesse,
CK
Hallo,
Da warst Du aber flott, hatte gedacht, das braucht bestimmt
bis morgen, bis da jemand drauf antwortet ;-)Nee, nicht bei so interessanten Themen :)
Naja, da kann ich mir durchaus Aufregenderes vorstellen. ;-)
Wofuer brauchst du das eigentlich? Schreibelst du an 'nem
Browser 'rum?
Nein, da gibt es genug, glaube ich ;-)
Ist für eine serverseitige Protokollschnittstelle.
War mir nicht ganz sicher und dachte: frag einfach mal.
so short
Christoph Zurnieden
PS:
Hast Du immer noch Probleme mit Deinen Mails? (Ich hoffe Du verstehst, worauf ich hinaus will)
CZ
Hallo Christoph,
Naja, da kann ich mir durchaus Aufregenderes vorstellen.
;-)
Also, ich persoenlich finde HTTP *sehr* interessant.
Hast Du immer noch Probleme mit Deinen Mails? (Ich hoffe Du
verstehst, worauf ich hinaus will)
Ja. Ich habe meinen Key in der Firma liegen und arbeite im
Moment von daheim aus *schnief*
Gruesse,
CK