charliehnabble wrote:
.... Maybe it is connection:close
that makes Tomcat not send a chunk length. I don't know why Tomcat doesn't
put a content-length header in that case.
Now that I believe is normal. As I recall the HTTP RFC (2616?), that is
the only case where the server does not have to send a content length :
when it closes the connection at the end of the response anyway.
The point is, the client must have a non-ambiguous way of knowing when
the response content ends.
So there is either :
- a persistent connection with a content-length header
- a persistent connection with chunked encoding (where each chunk
indicates a length, and there is a last chunk of 0 length)
- or a connection closing at the end of the response body, with or
without a content-length header (kind of, without is in that case tolerated)
Where this all leaves your problem, I don't know.
You could, in your webapp, force a content-length header to be output no
matter what. (Assuming you know in advance what this length is going to
be, before you write the first byte of it to the response output stream)
It seems to me that you should find out precisely what your "device" or
"router" does not like : maybe it just does not like a non-chunked
answer /without/ a content-length header (which should technically be
ok, but maybe it is a bit picky).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
