Looks like that may be a hint to recalculate it after rewriting occurs since the length with change? Have you looked into that? It certainly shouldn't make it to the service endpoint as -1 - if that is the case it should be fixed for sure.
On Thu, Jun 20, 2013 at 10:24 AM, Dilli Arumugam (JIRA) <[email protected]>wrote: > Dilli Arumugam created KNOX-80: > ---------------------------------- > > Summary: Knox should not set HTTP request content length as -1 > Key: KNOX-80 > URL: https://issues.apache.org/jira/browse/KNOX-80 > Project: Apache Knox > Issue Type: Bug > Components: Server > Affects Versions: 0.3.0 > Reporter: Dilli Arumugam > Fix For: 0.3.0 > > > I see gateway-provider-identity-assertion- > > pseudo/src/main/java/org/apache/hadoop/gateway/filter/IdentityAssertionHttpServletRequestWrapper.java > > is returning -1 as Content-Length if contentType.startsWith( > "application/x-www-form-urlencoded" ). > > This not standard compatible and I believe is error prone. > > Please see http 1.1 specs at > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 > > Quoting from the specs: > Any Content-Length greater than or equal to zero is a valid value. Section > 4.4 describes how to determine the length of a message-body if a > Content-Length is not given. > > So, we should not return content-length value as -1. > If we rewrite the content and change the entity length in the process, we > have to compute and set the correct content-length or try to leverage > chunked encoding where you do not specify the content-length header. > > > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >
