DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10541>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10541 Content-length header should be automatically set for buffered Servlets/JSPs [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2002-07-08 18:40 ------- Please read the following comments - if you choose to set the bug back to "resolved wontfix" I won't continue to reopen, but please do consider the following first: (thanks) 1) The spec is not specifying how the transport layer behaves. The spec is saying that asking a buffer to be used (even if used by default as with JSP's) also includes asking the container to set the content length for the servlet/jsp. In other words, you can think if it in a similar manner to the actual servlet saying "please call setContentLength()" for me. 2) HTTP 1.1 clearly does strongly encourage the use of the Content-length header (or chunked transfer encoding instead) whenever possible -- see sections 4.4, 10.4.12, and 14.14 in RFC 2616. 3) I don't see why you would need to change connectors to support this. Normally, if a servlet programatically sets the content length, the AJP connector passes this header along fine. If the servlet sets a buffer size, this is in fact asking the servlet container to set the content length for it -- at this point nothing has yet been passed to the connector, so there is no reason for the connector to know the difference between the two situations. (let me know if I'm not explaining this clearly). 4) Recent versions of Commercial servlet containers (e.g. BEA Weblogic) DO take care of the content length in the buffered situation, as the spec says. While this doesn't prove that what the spec says is the right thing to do, I think it makes a great deal of sense. I do hope you might re-consider adding this feature to Tomcat. At any rate, thanks for all the great work you guys do! -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
