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.

Author orsenthil
Recipients giampaolo.rodola, orsenthil, python-dev, skrah, vinay.sajip
Date 2011-05-10.10:07:54
SpamBayes Score 6.6148786e-08
Marked as misclassified No
Message-id <20110510100746.GA18370@kevin>
In-reply-to <1305018778.63.0.303156881029.issue12039@psf.upfronthosting.co.za>
Content
On Tue, May 10, 2011 at 09:12:58AM +0000, Vinay Sajip wrote:
> Either omitting the end_headers() call was always an error but
> previously undetected, or the requirement to always call
> end_headers() is new and this should be documented. I'm not sure
> which of these is the case, but leaving open since I think the
> http.server documentation ought to be changed. Apart from this I

end_headers was added 3.2, so that all the headers can be cached and
sent at once instead of writing one header at a time to the output
stream. This is a new change in 3.3, where end_header calls
flush_header which does the job of writing and clearing the cache.

The need to call end_header always is new (at least from 3.2, because
I see the http.server code itself using end_header at the end whenever
it uses send_header)

Following is the information in the updated docs.

.. method:: send_header(keyword, value)

         Adds the HTTP header to an internal buffer which will be
         written to the output stream when either :meth:`end_headers`
         or :meth:`flush_headers` is invoked. 

I think, a little change in wording saying that end_headers or
flush_headers MUST BE called would make it more prominent.
History
Date User Action Args
2011-05-10 10:07:55orsenthilsetrecipients: + orsenthil, vinay.sajip, giampaolo.rodola, skrah, python-dev
2011-05-10 10:07:54orsenthillinkissue12039 messages
2011-05-10 10:07:54orsenthilcreate