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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
