https://bz.apache.org/bugzilla/show_bug.cgi?id=64775
--- Comment #4 from Stefan Mayr <ste...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
