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=21378>. 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=21378 Transfer-Encoding: identity not supported + possible patch ------- Additional Comments From [EMAIL PROTECTED] 2003-07-07 21:29 ------- Eric, I do not know it for sure either. I am just trying to make some (more or less) informed guesses. One thing for sure the RFC is terribly contradictory on this issue. -------------------------------------------------------------------- 3.6 Transfer Codings ... Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4). ... -------------------------------------------------------------------- so, what I can gather from the above paragraph is that chunk encoding must be used anyway to ensure that the content length could be determined, no matter what additional encodings are appled. There's one thing I am pretty sure about that content length & transfer encoding directives are mutually exclusive. -------------------------------------------------------------------- 4.4 Message Length ... 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. ... -------------------------------------------------------------------- Anyways, what that all means to me that if ("chunked".equalsIgnoreCase(transferEncodingHeader.getValue())) is really not good enough. The code needs to be made more robust when dealing with composite transfer encodings Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
