Ticket #629 (defect)
Opened 2 years ago
Last modified 2 years ago
CherryPyWSGIServer fails to send Content-Length during HTTP 1.0 Keep-Alive
Status: closed (fixed)
| Reported by: | pjenvey@groovie.org | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.0 |
| Component: | CherryPy code | Keywords: | wsgi |
| Cc: |
Escape character is '^]'. GET /test HTTP/1.0 Connection: Keep-Alive HTTP/1.1 200 OK Connection: Keep-Alive content-type: text/html; charset=UTF-8 Date: Sun, 24 Dec 2006 08:30:49 GMT Server: CherryPy/3.0.0 <html><body>The response</body></html>
In this case chunked encoding can't be used (incompatible with HTTP/1.0), so Content-Length is required. As per RFC 2068 19.7.1:
Change History
12/24/06 02:51:27: Modified by pjenvey@groovie.org
12/24/06 16:17:13: Modified by fumanchu
- owner changed from rdelon to fumanchu.
- status changed from new to assigned.
- milestone set to 3.0.
Hmm. My only question is whether the server should, in that case, try to buffer the response and thereby calculate the Content-Length, or should just close the connection after responding. In my opinion, the latter would be more appropriate; since the CP user must have set 'response.stream' to True, it seems wrong to buffer.
The spec says, "An HTTP/1.1 server may also establish persistent connections with HTTP/1.0 clients upon receipt of a Keep-Alive connection token. However, a persistent connection with an HTTP/1.0 client cannot make use of the chunked transfer-coding, and therefore MUST use a Content-Length for marking the ending boundary of each message." My reading of that is that the persistent connection "MUST use a Content-Length", but the server is equally free to close the conn to signal the end of the response.
12/24/06 19:24:20: Modified by pjenvey@groovie.org
That's right, you can close the connection to avoid the Content-Length requirement
Mind you ab uses the HTTP/1.0 protocol (at least in versions 1.3 and 2.0, not sure about >= 2.1), even when using the keepalive option
12/24/06 22:09:48: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
Fixed in [1565].
This is on 3.0.0 release