rj...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
