Bug(?) and suggested solution for chunked transfer-encoding POST request

[Adrian Sampaleanu <as...@activience.com>]

We are having a problem with Catalina 4.1.12 (I believe we also had issues with previous versions, but can't say for sure) with respect to how POSTed requests are handled if the transfer encoding is "chunked". It seems that request parameters in the content are not processed in this case.

Looking at the source, in HttpRequestBase.java the method parseParameters() does the following check:

if ("POST".equals(getMethod()) && (getContentLength() > 0)
    && (this.stream == null)
    && "application/x-www-form-urlencoded".equals(contentType)) {

   ...
   Processing of params in the content
   ...
}

The problem is that with chunked transfer encoding the content length condition isn't met since parseHeaders() in HttpProcessor.java only sets this if the content-length header exists which is not the case with chunked transfers. It would seem that the check in HttpRequestBase.java shoud really be:

String transferEncoding = request.getHeader("Transfer-Encoding");
boolean chunked = ((transferEncoding != null) && (transferEncoding.indexOf("chunked") != -1));

if ("POST".equals(getMethod()) && (getContentLength() > 0 || chunked)
    && (this.stream == null)
    && "application/x-www-form-urlencoded".equals(contentType))


If I'm way off base, does anyone have the real solution?

Thanks,
Adrian Sampaleanu
Activience Inc.

	 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Bug(?) and suggested solution for chunked transfer-encoding POST request

[Ryan Hoegg <rh...@isisnetworks.net>]

Remy Maucherat wrote:

> Adrian Sampaleanu wrote:
>
>> We are having a problem with Catalina 4.1.12 (I believe we also had 
>> issues with previous versions, but can't say for sure) with respect 
>> to how POSTed requests are handled if the transfer encoding is 
>> "chunked". It seems that request parameters in the content are not 
>> processed in this case.
>
>
> This is not legal. In HTTP/1.1, FORM encoded data of a POST must have 
> a content-length. You can do the parsing yourself, of course.
>
> Rémy 

See RFC2616, Section 4.4.  An excerpt:

Messages MUST NOT include both a Content-Length header field and a
   non-identity transfer-coding. If the message does include a non-
   identity transfer-coding, the Content-Length MUST be ignored.

In looking through RFC2616, I didn't see any special case for POST 
requests with FORM encoding that either required the use of 
Content-Length (thereby prohibiting the use of Transfer-Encoding: 
chunked) or vice versa.  If I missed it or if its in a different RFC 
please post a reference.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Bug(?) and suggested solution for chunked transfer-encoding POST request

[Remy Maucherat <re...@apache.org>]

Adrian Sampaleanu wrote:

> We are having a problem with Catalina 4.1.12 (I believe we also had 
> issues with previous versions, but can't say for sure) with respect to 
> how POSTed requests are handled if the transfer encoding is "chunked". 
> It seems that request parameters in the content are not processed in 
> this case.

This is not legal. In HTTP/1.1, FORM encoded data of a POST must have a 
content-length. You can do the parsing yourself, of course.

Rémy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>