[Bug 64775] mod_jk is sending both Content-Length and Transfer-Encoding

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64775

--- Comment #4 from Stefan Mayr <st...@mayr-stefan.de> ---
After some testing I can reproduce this issue

demo.jsp:
  <%@ page contentType="text/plain; charset=UTF-8" session="false" %>
  <%
  response.setHeader("Content-Length","");
  for(int i = 0; i < 8192; ++i) { out.print("."); }
  %>

This produces the headers as you described:
  Transfer-Encoding: chunked
  Content-Length:

If we query this JSP through mod_jk instead of the Tomcat http connector this
header becomes
  Transfer-Encoding: chunked
  Content-Length: 0

According to RFC2616 both outputs are wrong. Just one contains one less error.

Citing the RFC:

14.13 Content-Length

   The Content-Length entity-header field indicates the size of the
   entity-body, in decimal number of OCTETs, sent to the recipient or,
   in the case of the HEAD method, the size of the entity-body that
   would have been sent had the request been a GET.

       Content-Length    = "Content-Length" ":" 1*DIGIT

   An example is

       Content-Length: 3495

   Applications SHOULD use this field to indicate the transfer-length of
   the message-body, unless this is prohibited by the rules in section
   4.4.

   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 "Content-Length: 0" complies with the spec while "Content-Length: " does
not. So mod_jk fixes that header which is generally good.
Now you have a client that can handle one case but not the other. Other clients
are different. I tested with curl (because man applications use libcurl) and it
is not happy with both cases:

Content-Length is empty:
  curl: (8) Invalid Content-Length: value

Content-Length is set to zero:
  Excess found: excess = 8184 url = /demo.jsp (zero-length body)

Regarding Content-Length and Transfer-Encoding the RFC is hard to read because
we now have to differentiate between the response body and messages in the
chunked encoding. From my understanding it is not allowed to use both headers
in a response:

   3.If a Content-Length header field (section 14.13) is present, its
     decimal value in OCTETs represents both the entity-length and the
     transfer-length. The Content-Length header field MUST NOT be sent
     if these two lengths are different (i.e., if a Transfer-Encoding
     header field is present). If a message is received with both a
     Transfer-Encoding header field and a Content-Length header field,
     the latter MUST be ignored.

Now we could blame the client for not ignoring the Content-Length field. But I
think it would be better to find out why your application sens out an empty
Content-Length header and remove that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org