W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

Re: HTTP rfc related question, Content-length: 0 in GET request

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Thu, 22 Jun 2006 10:39:03 -0700
Message-Id: <200606221739.k5MHd3PA013395@pobox-pa.hpl.hp.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Kuba Witczak <czesacz@gmail.com>, ietf-http-wg@w3.org

Julian Reschke <julian.reschke@gmx.de> writes:
    Kuba Witczak schrieb:

    > The problem is that a system, which relies on HTTP protocol, refuses to
    > accept GET requests with header 'Content-length: 0'. This header added
    > to request doesn't bring any information, and should be ignored by a
    > system which relies on HTTP protocol, am i correct?
    No, it shouldn't be ignored. It should be processed. In this 
    *particular* case that's the same as ignoring, but in theory the request 
    *could* have a request body (although RFC2616 currently doesn't define 
    what that would mean). In the latter case, the recipient would need to 
    read the request body (potentially throwing it away afterwards).

    > Is there any general rule in HTTP/1.1 protocol which allows or forbids
    > 'Content-length: 0' header in GET requests?
    There's no rule that forbids it.

The same question appeared on comp.protocols.tcp-ip, and Barry
Margolin pointed out:

    See section 4.3, where it says:

       The presence of a message-body in a request is signaled by the
       inclusion of a Content-Length or Transfer-Encoding header field in
       the request's message-headers. A message-body MUST NOT be included in
       a request if the specification of the request method (section 5.1.1)
       does not allow sending an entity-body in requests.

    Since the specification of the GET request doesn't allow sending a body
    in the request, you MUST NOT include a Content-Length or
    Transfer-Encoding header. 

I'm not sure he's correct that RFC2616 prohibits sending a
message-body with a GET method.  5.1.1 (Method) doesn't actually
say anything about this.  Section 9.3 (GET) doesn't either.
The definitions for PUT and POST do refer to "the enclosed entity",
which implicitly "allow[s] sending an entity-body".  Anyway,
I think the spec is a little ambiguous in this respect, since
4.3 implies that (somewhere else) there is a definitive statement
about which methods do and don't allow entity-bodies in requests.
As far as I can tell, there isn't.

Nevertheless, what has become known as the "robustness principle":

   In general, an implementation must be conservative
   in its sending behavior, and liberal in its receiving behavior.
   [RFC791, section 3.2]

implies that rejecting a GET with "Content-length: 0" is being

HOWEVER, Barry also points out:

   I think a number of firewalls block these because they have been
   involved in some exploits. 

I'm not specifically aware of which exploits are involved here;
I think the problem might be that a malicious request actually does
have a "body" that starts with another set of HTTP request headers,
thus bypassing certain checks along the way.

Anyway, I don't know if the situation is as clear as it should
be.  The spec seems to leave a little too much room for confusion,
and the security issue might be worth documenting as "advice for
proxy and server implementors."


P.S.: Barry's message is available via:

Received on Thursday, 22 June 2006 17:39:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:27 UTC