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

From: "Kuba Witczak" <[email-masked]>
Date: Wed, 21 Jun 2006 14:17:24 +0000

Hi,

I'm not sure if this is the right group to ask this question. If you
know a better place please give me such advice.

The problem relates to HTTP protocol specification. I studied the RFC
2616 which describes HTTP/1.1, but AFAIC the situation is not described
directly there.

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?

The sample request which causes error:

GET /somepath/gfx.png HTTP/1.1
...som other headers
Content-length: 0

Perhaps you've faced similar problem previously and have some
experiences.
Is there any general rule in HTTP/1.1 protocol which allows or forbids
'Content-length: 0' header in GET requests?

I've really tried to find it on my own in RFC 2616, but I might missed
some valuable information.
Please share your opinions.

Thanks in advance,
Kuba

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 21 Jun 2006 15:38:01 +0100 (BST)

> system which relies on HTTP protocol, am i correct?

Why ignored? It precisely says that the Entity field of the request is
empty. Content-Length: 0 is a valid value.

> 'Content-length: 0' header in GET requests?

It sounds like your system is in fault rather than HTTP :)
Or I don't understand your correctly.
In any case, the only place to look:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

- Sylvain

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Jun 2006 09:56:22 +0200

> 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).

> 'Content-length: 0' header in GET requests?

There's no rule that forbids it.

> Please share your opinions.

Best regards, Julian

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 22 Jun 2006 10:05:38 -0400

On 6/21/06, Kuba Witczak <[email-masked]> wrote:
> accept GET requests with header 'Content-length: 0'.

I ran into this behaviour a few years ago, on, IIRC, Tomcat 4.

As folks have pointed out, it's a bug.

Mark.

---

From: Jeffrey Mogul <[email-masked]>
Date: Thu, 22 Jun 2006 10:39:03 -0700

Julian Reschke <[email-masked]> writes:

    
    
    [...]

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
over-cautious.

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."

-Jeff

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

http://groups.google.com/group/comp.protocols.tcp-ip/browse_thread/thread/9c51adab8132c0b7/a701d2edcd9c089b?lnk=st&q=margolin+%22Content-length%3A+0%22&rnum=1&hl=en#a701d2edcd9c089b