hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
Date Mon, 07 Jul 2003 21:29:43 GMT
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 olegk@apache.org  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

Mime
View raw message