New submission from Brian Jones <bkjo...@gmail.com>:
In trying to write a PyPI service, I of course need to support the registration
and upload features of setup.py, which uses distutils for those actions. One
thing making this a bit more difficult than need be is the fact that
distutils.command.register and distutils.command.upload both use bare line
feeds as a line terminator in the HTTP message headers. While there are
probably tolerant servers out there, I think this behavior should be considered
a bug in light of the HTTP spec, which reads:
"The line terminator for message-header fields is the sequence CRLF. However,
we recommend that applications, when parsing such headers, recognize a single
LF as a line terminator and ignore the leading CR."
The second sentence can be interpreted in multiple ways that either agree with
or contradict the first sentence, but the first sentence is at least perfectly
clear, and I'd like to see "\r\n" added to the beginning of (specifically in
this case) the Content-Disposition headers assembled by
distutils.command.upload and distutils.command.register.
The change involves taking identical lines in each file that currently look
like this:
title = '\nContent-Disposition: form-data; name="%s"' % key
...and making them look like this:
title = '\r\nContent-Disposition: form-data; name="%s"' % key
The result is that servers which do not support a lax adherence to the protocol
will still be able to support users of distutils in Python 2.6, 2.7, and 3.1
(and maybe others).
----------
messages: 122192
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: distutils.command.upload/register HTTP message headers: bad line
termination
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
