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 eric.araujo
Recipients Brian.Jones, eric.araujo, jerub, mitchellh, orsenthil, r.david.murray, tarek
Date 2011-10-23.02:13:08
SpamBayes Score 0.00010000907
Marked as misclassified No
Message-id <1319335989.56.0.115309792266.issue10510@psf.upfronthosting.co.za>
In-reply-to
Content
Mitchell Hashimoto provided this link on a duplicate report:

> RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that headers must be separated
> by CRLF. Specifically, the above "\n\n" for the header separator is causing issues with some
> minimal RFC-compliant web servers.

So I checked the RFC carefully again and found this:

> http://tools.ietf.org/html/rfc2616#section-3.7.1
>
> When in canonical form, media subtypes of the "text" type use CRLF as
> the text line break. HTTP relaxes this requirement and allows the
> transport of text media with plain CR or LF alone representing a line
> break when it is done consistently for an entire entity-body. HTTP
> applications MUST accept CRLF, bare CR, and bare LF as being
> representative of a line break in text media received via HTTP

The requests we send are multipart/form-data, so the RFC exception for text/* would not apply.  On one hand, I don’t think we can say that sending LF is not a bug, on the other hand, I believe nearly all HTTP servers just accept all newlines anyway.
History
Date User Action Args
2011-10-23 02:13:09eric.araujosetrecipients: + eric.araujo, orsenthil, jerub, tarek, r.david.murray, mitchellh, Brian.Jones
2011-10-23 02:13:09eric.araujosetmessageid: <1319335989.56.0.115309792266.issue10510@psf.upfronthosting.co.za>
2011-10-23 02:13:08eric.araujolinkissue10510 messages
2011-10-23 02:13:08eric.araujocreate