You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <o....@dplanet.ch> on 2003/02/07 22:47:09 UTC
Re: DO NOT REPLY [Bug 16892] New: - Empty response body is not
properly handled when chunked encoding is used
Folks
I am not certain if this kind of behavior is in violation of the RFC
2068. Any opinions?
Oleg
On Fri, 2003-02-07 at 22:44, bugzilla@apache.org wrote:
> 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=16892>.
> 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=16892
>
> Empty response body is not properly handled when chunked encoding is used
>
> Summary: Empty response body is not properly handled when chunked
> encoding is used
> Product: Commons
> Version: 2.0 Alpha 1
> Platform: All
> OS/Version: All
> Status: NEW
> Severity: Major
> Priority: Other
> Component: HttpClient
> AssignedTo: commons-httpclient-dev@jakarta.apache.org
> ReportedBy: olegk@apache.org
>
>
> IIS 5.0 server, when returning no content in response to an HTTP/1.1 request,
> still includes "Transfer-Encoding: chunked" response header. As HttpClient
> always expects chunk-encoded stream to be properly terminated, an
> HttpRecoverableException exception results, when no content is sent back
>
> =====================================================================
>
> POST /someurl.aspx HTTP/1.1
> Content-Length: 1132
> Host: xxx.xxx.xxx.xxx
> User-Agent: Jakarta Commons-HttpClient/2.0alpha2
> Content-Type: multipart/form-data; boundary=----------------314159265358979323846
>
> ------------------314159265358979323846
> Content-Disposition: form-data; name="nmFile"; filename="xxxxxxxxx.xml"
> Content-Type: application/octet-stream
>
> <... content removed ...>
>
> ------------------314159265358979323846--
>
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/5.0
> Date: Sat, 08 Feb 2003 15:22:26 GMT
> Transfer-Encoding: chunked
> Cache-Control: private
> Content-Type: text/html
>
> =====================================================================
>
> Bug reported by Jim Crossley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 16892] New: - Empty response body is not
properly handled when chunked encoding is used
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
Odi, Jeff
I tend to interpret the word of RFC the same way. However, the RFC
appears a bit fuzzy on whether it is permissible to include
"Transfer-Encoding: chunked" response header without actually providing
any content in response. Anyways, to an extent this is irrelevant. We
have to coexist with IIS regardless of its lousy standards compliance
record
Oleg
On Sat, 2003-02-08 at 14:21, Ortwin Glück wrote:
> If a Transfer-Encoding: chunked header is present, the body must at
> least contain the last chunk, which is:
>
> 0<CRLF>
> <CRLF>
>
> Without the last chunk beeing present we can not detect if there is a
> body at all! The last chunk not beeing present violates the RFC:
> last-chunk has no asterix in front of it.
>
> Odi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 16892] New: - Empty response body is not
properly handled when chunked encoding is used
Posted by Ortwin Glück <or...@nose.ch>.
If a Transfer-Encoding: chunked header is present, the body must at
least contain the last chunk, which is:
0<CRLF>
<CRLF>
Without the last chunk beeing present we can not detect if there is a
body at all! The last chunk not beeing present violates the RFC:
last-chunk has no asterix in front of it.
Odi
Re: DO NOT REPLY [Bug 16892] New: - Empty response body is not
properly handled when chunked encoding is used
Posted by Jeffrey Dever <js...@sympatico.ca>.
2068 has been replaced by 2616, so I'll use that as the basis for this
discussion.
To determine if this is compliant behaviour, there are a couple of
questions to answer.
1) Does a empty body qualify as a chunked body?
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
I don't quite know what a "last-chunk" is, but is is not optional, nor
is the CRLF. So this says to me that a chunked body cannot be an empty
body.
2) But does a response to a POST require a body at all?
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result.
Clearly a 200 response should have a body. If there is no body, a 204
should be returned.
So I would conclude that IIS is violating the standard in this regard.
But we still have to cope with Microcruft non-standard, non-compliant,
buggy behaviour.
Jeff Dever
Oleg Kalnichevski wrote:
>Folks
>
>I am not certain if this kind of behavior is in violation of the RFC
>2068. Any opinions?
>
>Oleg
>
>On Fri, 2003-02-07 at 22:44, bugzilla@apache.org wrote:
>
>
>>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=16892>.
>>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=16892
>>
>>Empty response body is not properly handled when chunked encoding is used
>>
>> Summary: Empty response body is not properly handled when chunked
>> encoding is used
>> Product: Commons
>> Version: 2.0 Alpha 1
>> Platform: All
>> OS/Version: All
>> Status: NEW
>> Severity: Major
>> Priority: Other
>> Component: HttpClient
>> AssignedTo: commons-httpclient-dev@jakarta.apache.org
>> ReportedBy: olegk@apache.org
>>
>>
>>IIS 5.0 server, when returning no content in response to an HTTP/1.1 request,
>>still includes "Transfer-Encoding: chunked" response header. As HttpClient
>>always expects chunk-encoded stream to be properly terminated, an
>>HttpRecoverableException exception results, when no content is sent back
>>
>>=====================================================================
>>
>>POST /someurl.aspx HTTP/1.1
>>Content-Length: 1132
>>Host: xxx.xxx.xxx.xxx
>>User-Agent: Jakarta Commons-HttpClient/2.0alpha2
>>Content-Type: multipart/form-data; boundary=----------------314159265358979323846
>>
>>------------------314159265358979323846
>>Content-Disposition: form-data; name="nmFile"; filename="xxxxxxxxx.xml"
>>Content-Type: application/octet-stream
>>
>><... content removed ...>
>>
>>------------------314159265358979323846--
>>
>>HTTP/1.1 200 OK
>>Server: Microsoft-IIS/5.0
>>Date: Sat, 08 Feb 2003 15:22:26 GMT
>>Transfer-Encoding: chunked
>>Cache-Control: private
>>Content-Type: text/html
>>
>>=====================================================================
>>
>>Bug reported by Jim Crossley
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>