Adjusted how libcurl treats HTTP 1.1 responses without content-lenth or

chunked encoding (that also lacks "Connection: close"). It now simply
assumes that the connection WILL be closed to signal the end, as that is how
RFC2616 section 4.4 point #5 says we should behave.
This commit is contained in:
Daniel Stenberg 2007-06-25 13:58:14 +00:00
parent 3dff58b3aa
commit 974fa1242a
4 changed files with 15 additions and 7 deletions

View File

@ -6,6 +6,12 @@
Changelog
Daniel S (25 June 2007)
- Adjusted how libcurl treats HTTP 1.1 responses without content-lenth or
chunked encoding (that also lacks "Connection: close"). It now simply
assumes that the connection WILL be closed to signal the end, as that is how
RFC2616 section 4.4 point #5 says we should behave.
Version 7.16.3 (25 June 2007)
Daniel S (23 June 2007)

View File

@ -15,7 +15,8 @@ This release includes the following changes:
This release includes the following bugfixes:
o
o adjusted how libcurl treats HTTP 1.1 responses without content-lenth or
chunked encoding
This release includes the following known bugs:

View File

@ -577,11 +577,12 @@ CURLcode Curl_readwrite(struct connectdata *conn,
(k->httpversion >= 11) )
/* On HTTP 1.1, when connection is not to get closed, but no
Content-Length nor Content-Encoding chunked have been
received, there is no body in this response. We don't set
stop_reading TRUE since that would also prevent necessary
authentication actions to take place. */
conn->bits.no_body = TRUE;
received, according to RFC2616 section 4.4 point 5, we
assume that the server will close the connection to
signal the end of the document. */
infof(data, "no chunk, no close, no size. Assume close to "
"signal end\n");
conn->bits.close = TRUE;
}
if (417 == k->httpcode) {

View File

@ -10,7 +10,7 @@ HTTP GET
# Server-side
<reply>
<data>
HTTP/1.1 200 OK
HTTP/1.1 200 OK swsclose
</data>
</reply>