HTTP rfc related question, Content-length: 0 in GET request
chq
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?
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
Barry Margolin
"chq" <cze...@gmail.com> wrote:
> 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?
>
> 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 think a number of firewalls block these because they have been
involved in some exploits.
>
> 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
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.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
chq
> 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.
Are you sure that it's forbidden for GET requests? I've searched the
RFC 2616 for such statement, but without success. Could you find such
sentence?
thx in advance,
Kuba
Barry Margolin
"chq" <cze...@gmail.com> wrote:
I think the requests that have a body say so explicitly, and the rest
are implicitly forbidden. Do other non-body commands say so explicitly?
What would the body of a GET request do?
chq
Barry Margolin wrote:
> I think the requests that have a body say so explicitly, and the rest
> are implicitly forbidden. Do other non-body commands say so explicitly?
>
> What would the body of a GET request do?
Well, I believe that's not specified in RFC 2616, but I believe it
isn't forbidden and might be useful for some fancy HTTP protocol based
protocols.
I've asked the same question on w3.org mailing list and Jeffrey Mogul
has similar opinion in this topic, but perhaps we misunderstood
something ...
The thread is available here:
http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/
Thanks in advance,
Kuba
Barry Margolin
"chq" <cze...@gmail.com> wrote:
As he pointed out, the RFC never explicitly states which methods
prohibit bodies. But the section I quoted implies that bodies are
allowed in some methods and prohibited in some others. There are then
three possible conclusions from this:
1) The section that mentioned bodies being prohibited was written to
allow for the possibility that future methods might be defined (perhaps
in extension RFCs) that explicitly prohibit bodies.
2) The intent is that the methods that don't explicitly say that bodies
are allowed prohibit them.
3) They screwed up -- when they wrote the paragraph I quoted they
expected to prohibit bodies in some methods, but never went through with
that and forgot to correct that paragraph.
I went with #2 -- it makes the document self-consistent.