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 20:45 ------- Brent, I don't suppose you could provide a wire log? It might help clarify. Oleg, I have no idea whether my analysis is correct or not. I only noticed this issue due to my almost pathological interest in making sure streams are properly wrapped. The RFC apparently got it wrong on this point. From section 3.6: "The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5)." Except that there is no section 3.6.2. I found these two links: http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001SepDec/0018.html http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1998q3/0135.html Which seem to suggest that leaving "identity" in was a mistake. Maybe you knew all this, I certainly didn't. In any case, your assertion that only "chunked" is valid appears to be wrong, in that "gzip", "compress", and "deflate" are possible values too. Anyway, I think it is still necessary to be able to determine the content-length, so I think my original suggestion might be appropriate, if we support the "identity" transfer encoding at all. I've not had a chance to look at the patches you've supplied, just mining for information so far. -Eric. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
