You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 1998/06/29 20:46:37 UTC
ap_setup_client_block() perversity
If read_policy is REQUEST_CHUNKED_ERROR, and the Transfer-Encoding is
"chunked" and there is no Content-Length, then HTTP_LENGTH_REQUIRED is
returned. However, if there is a Content-Length, then HTTP_BAD_REQUEST
is returned. This seems odd to me, but perhaps there is a rational
explanation. Any offers?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: ap_setup_client_block() perversity
Posted by Marc Slemko <ma...@worldgate.com>.
Because the spec says if it is chunked then there can be no
content-length?
2068:
Messages MUST NOT include both a Content-Length header field and the
"chunked" transfer coding. If both are received, the Content-Length
MUST be ignored.
Technically, we are not doing what the spec says, but I think that is the
general idea behind that code...
On Mon, 29 Jun 1998, Ben Laurie wrote:
> If read_policy is REQUEST_CHUNKED_ERROR, and the Transfer-Encoding is
> "chunked" and there is no Content-Length, then HTTP_LENGTH_REQUIRED is
> returned. However, if there is a Content-Length, then HTTP_BAD_REQUEST
> is returned. This seems odd to me, but perhaps there is a rational
> explanation. Any offers?
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
> and Technical Director|Email: ben@algroup.co.uk |
> A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
>
> WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
>
Re: ap_setup_client_block() perversity
Posted by Dean Gaudet <dg...@arctic.org>.
This would be a good comment to add to the source...
Dean
On Mon, 29 Jun 1998, Ben Laurie wrote:
> Alexei Kosut wrote:
> >
> > On Mon, 29 Jun 1998, Ben Laurie wrote:
> >
> > > If read_policy is REQUEST_CHUNKED_ERROR, and the Transfer-Encoding is
> > > "chunked" and there is no Content-Length, then HTTP_LENGTH_REQUIRED is
> > > returned. However, if there is a Content-Length, then HTTP_BAD_REQUEST
> > > is returned. This seems odd to me, but perhaps there is a rational
> > > explanation. Any offers?
> >
> > Section 4.4 of RFC 2068:
> >
> > "Messages MUST NOT include both a Content-Length header field and the
> > "chunked" transfer coding."
> >
> > So it is a bad request... (although the next sentence does say "If both
> > are received, the Content-Length MUST be ignored. Which, unfortunately, we
> > can't do, because the length isn't guaranteed to be the same as the actual
> > entity length, which is defined by the chunking instead, but which we'd
> > have to strip out to give to the CGI, but can't. So given that a 411 only
> > requests the addition of a Content-Length, and not specifically the
> > removing of any transfer-coding (though it's implied), and we can't
> > properly parse the request, a 400 error reponse is as good as any other.
> > Better, in fact).
>
> Ah, I get it. You mean if we get T-E and no C-L, we say "give me a C-L
> (instead of a T-E)". If we get both, we say "sod off". (only in the case
> where someone wants to say REQUEST_CHUNKED_ERROR, of course, which leads
> me on to, err, why would anyone do that?). Thankyou.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
> and Technical Director|Email: ben@algroup.co.uk |
> A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
>
> WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
>
Re: ap_setup_client_block() perversity
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Mon, 29 Jun 1998, Ben Laurie wrote:
> Ah, I get it. You mean if we get T-E and no C-L, we say "give me a C-L
> (instead of a T-E)". If we get both, we say "sod off". (only in the case
Yep, that's about the size of it.
> where someone wants to say REQUEST_CHUNKED_ERROR, of course, which leads
> me on to, err, why would anyone do that?). Thankyou.
If they need a content lenght. mod_cgi uses REQUEST_CHUNKED_ERROR, for
example, because CGI/1.1 specifies that the CONTENT_LENGTH environment
variable must be available for requests with an entity (that's how the CGI
spec defines the amount of client data to read, rather than something
sensible like reading until EOF).
Certainly, anyone writing a brand-new protocol today should properly deal
with chunked requests, but unfortunately we're stuck with legacy stuff
that this code deals with.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: ap_setup_client_block() perversity
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Mon, 29 Jun 1998, Ben Laurie wrote:
>
> > If read_policy is REQUEST_CHUNKED_ERROR, and the Transfer-Encoding is
> > "chunked" and there is no Content-Length, then HTTP_LENGTH_REQUIRED is
> > returned. However, if there is a Content-Length, then HTTP_BAD_REQUEST
> > is returned. This seems odd to me, but perhaps there is a rational
> > explanation. Any offers?
>
> Section 4.4 of RFC 2068:
>
> "Messages MUST NOT include both a Content-Length header field and the
> "chunked" transfer coding."
>
> So it is a bad request... (although the next sentence does say "If both
> are received, the Content-Length MUST be ignored. Which, unfortunately, we
> can't do, because the length isn't guaranteed to be the same as the actual
> entity length, which is defined by the chunking instead, but which we'd
> have to strip out to give to the CGI, but can't. So given that a 411 only
> requests the addition of a Content-Length, and not specifically the
> removing of any transfer-coding (though it's implied), and we can't
> properly parse the request, a 400 error reponse is as good as any other.
> Better, in fact).
Ah, I get it. You mean if we get T-E and no C-L, we say "give me a C-L
(instead of a T-E)". If we get both, we say "sod off". (only in the case
where someone wants to say REQUEST_CHUNKED_ERROR, of course, which leads
me on to, err, why would anyone do that?). Thankyou.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: ap_setup_client_block() perversity
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Mon, 29 Jun 1998, Ben Laurie wrote:
> If read_policy is REQUEST_CHUNKED_ERROR, and the Transfer-Encoding is
> "chunked" and there is no Content-Length, then HTTP_LENGTH_REQUIRED is
> returned. However, if there is a Content-Length, then HTTP_BAD_REQUEST
> is returned. This seems odd to me, but perhaps there is a rational
> explanation. Any offers?
Section 4.4 of RFC 2068:
"Messages MUST NOT include both a Content-Length header field and the
"chunked" transfer coding."
So it is a bad request... (although the next sentence does say "If both
are received, the Content-Length MUST be ignored. Which, unfortunately, we
can't do, because the length isn't guaranteed to be the same as the actual
entity length, which is defined by the chunking instead, but which we'd
have to strip out to give to the CGI, but can't. So given that a 411 only
requests the addition of a Content-Length, and not specifically the
removing of any transfer-coding (though it's implied), and we can't
properly parse the request, a 400 error reponse is as good as any other.
Better, in fact).
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *