hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject Re: DO NOT REPLY [Bug 16892] New: - Empty response body is not properly handled when chunked encoding is used
Date Sat, 08 Feb 2003 08:07:44 GMT
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
>
>
>  
>



Mime
View raw message