You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by bu...@apache.org on 2003/02/07 22:44:24 UTC
DO NOT REPLY [Bug 16892] New: -
Empty response body is not properly handled when chunked encoding is used
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
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
>
>
>
>
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>.
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
>