This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: BaseHTTPServer's send_reponse adds extra "\r\n" when using HTTPMessage in input
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Yoav.Weiss, eric.araujo, orsenthil, petri.lehtinen
Priority: normal Keywords:

Created on 2011-06-29 09:35 by Yoav.Weiss, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg139401 - (view) Author: Yoav Weiss (Yoav.Weiss) Date: 2011-06-29 09:35
I'm using BaseHTTPServer's send_response (from within a class that inherits BaseHTTPRequestHandler) with the following:

    self.send_response(response.code, response.headers)
    self.end_headers()
    self.wfile.write(content)
    self.wfile.flush()
When response is a httplib's HTTPResponse object, and its headers inherits from rfc822.Message.

What I see is that message is printed as is, including all the headers trailing "\r\n", after which the send_response method (BaseHTTPServer.py:381) adds another "\r\n".
Then send_response adds the "Server" and "Date" headers.
Since the headers before Server & Date include "\r\n\r\n", Date & server are considered by the browser as the content.

Am I misusing BaseHTTPServer? If not, this is a bug and "\r\n" should be removed from line 381, or added only after a check that shows they are not already there at the headers end, or in case there are no input headers.
msg139698 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2011-07-03 19:45
It seems to me that you're indeed misusing it.

The correct way would be something like this (assuming response is a HTTPResponse object from httplib):

self.send_response(response.status)
for name, value in response.getheaders():
    self.send_header(name, value)
self.end_headers()

This is because send_response's second argument is the HTTP's "reason" field, i.e. invoking:

    self.send_response(123, 'FOOBAR')

results in 

    HTTP/1.1 123 FOOBAR\r\n

to be sent, followed by "Server" and "Date" headers. The second argument is not meant to be used for sending headers.

(When the second argument is omitted, a standard reason for the given status code is used.)
msg139749 - (view) Author: Yoav Weiss (Yoav.Weiss) Date: 2011-07-04 10:52
Thanks for correcting me. I guess I assumed that the "message" variable is
an HTTPMessage.
Is send_response documented somewhere? I failed to find a reference.

On Sun, Jul 3, 2011 at 9:45 PM, Petri Lehtinen <report@bugs.python.org>wrote:

>
> Petri Lehtinen <petri@digip.org> added the comment:
>
> It seems to me that you're indeed misusing it.
>
> The correct way would be something like this (assuming response is a
> HTTPResponse object from httplib):
>
> self.send_response(response.status)
> for name, value in response.getheaders():
>    self.send_header(name, value)
> self.end_headers()
>
> This is because send_response's second argument is the HTTP's "reason"
> field, i.e. invoking:
>
>    self.send_response(123, 'FOOBAR')
>
> results in
>
>    HTTP/1.1 123 FOOBAR\r\n
>
> to be sent, followed by "Server" and "Date" headers. The second argument is
> not meant to be used for sending headers.
>
> (When the second argument is omitted, a standard reason for the given
> status code is used.)
>
> ----------
> nosy: +petri.lehtinen
> resolution:  -> invalid
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue12439>
> _______________________________________
>
msg139784 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-07-04 16:20
See http://docs.python.org/dev/library/http.server#http.server.BaseHTTPRequestHandler.send_response
History
Date User Action Args
2022-04-11 14:57:19adminsetgithub: 56648
2011-07-25 19:02:21petri.lehtinensetstatus: open -> closed
2011-07-04 16:20:40eric.araujosetnosy: + eric.araujo
messages: + msg139784
2011-07-04 16:19:19eric.araujosetfiles: - unnamed
2011-07-04 10:52:44Yoav.Weisssetfiles: + unnamed

messages: + msg139749
2011-07-03 19:45:58petri.lehtinensetnosy: + petri.lehtinen
resolution: not a bug
messages: + msg139698
2011-06-29 13:19:25r.david.murraysetnosy: + orsenthil
2011-06-29 09:35:24Yoav.Weisscreate