Re: svn commit: r789792 - /tomcat/current/tc5.5.x/STATUS.txt

[Mark Thomas <ma...@apache.org>]

rjung@apache.org wrote:
>  * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=37084
> @@ -78,11 +78,19 @@
>    http://svn.apache.org/viewvc?rev=786487&view=rev
>    +1: markt
>    -1: 
> +  rjung: +1 in principle, but a few questions/suggestions:
> +      - Do we need to dechunk the read request body? I didn't see were this happens.
No. Like 6.0.x and trunk, it is handled in the Http11Processor by the
addition of a filter
> +      - Do chunked requests actually set a content-length?
No.
> If not, we have len == -1
> +        and will not enter the try/catch block. Maybe only a question of correct backport
> +        from trunk.
The patch applies a little further down than that. You end up with:
if (len > 0) {
  ...
} else if ("chunked".equalsIgnoreCase(
    coyoteRequest.getHeader("transfer-encoding"))) {
  ...
}
> +      - I think instead of: len == actualLen => non-chunked, else check transfer-encoding
Can't do that. You don't know actual length until you read the body
> +        it should be the other waqy round. If transfer-encoding is chunked, handle as chunked,
> +        else traditional.
I don't that it makes any difference. The two are mutually exclusive so
the order we check them in doesn't matter.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org