Serhiy Storchaka added the comment:
Trailing spaces, newlines and like were disabled in put_header() in issue22928.
Now we can start long-standing deprecation process for headers that don't
conform RFC 7230.
--
nosy: +serhiy.storchaka
stage: commit review - needs patch
versions:
Martin Panter added the comment:
See Issue 22928 for a patch making the “http.client” module even more stricter
with header field names and values.
--
nosy: +vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17322
karl added the comment:
Just a follow up for giving the stable version of the now new RFC version for
HTTP 1.1
HTTP header field names parsing
http://tools.ietf.org/html/rfc7230#section-3.2.4
--
___
Python tracker rep...@bugs.python.org
Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net:
--
nosy: +piotr.dobrogost
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17322
___
___
R. David Murray added the comment:
A crazy idea that occurred to me was to create an rfc822-style-header
management module, and share it between email, http, and urllib. We'd
probably break too many things backward-compatibility wise if we did that, but
I still think it is an interesting
karl added the comment:
R. David.:
A crazy idea that occurred to me was to create an rfc822-style-header
management module, and share it between email, http, and urllib.
Yes it is basically what I had in mind when I said:
Maybe the way forward in the future is to have a header factory
R. David Murray added the comment:
Aren't the folding rules are the same? The character set rules are different,
I think, but the email package is going to be flexible in that regard.
The email package also uses a data structure that is not a python dictionary
(it is actually a list with an
R. David Murray added the comment:
Given that this is an RFC violation it looks appropriate as a bug fix for all
active versions to me. The patch looks good, though I might decide to break up
the test.
--
nosy: +r.david.murray
stage: - commit review
type: - behavior
versions:
R. David Murray added the comment:
Ah, but that's a draft and not approved. Hmm. There is a possibility this
change would break code, if the code tries to look up a header by the same key
it used to set it. On the other hand, the key use for the set is already
modified by the existing
R. David Murray added the comment:
Here is a modified patch with the tests moved to test_urllib2. I'll give
people some time to comment on whether this should be applied at all, and if so
if it should be backported. I'm leaning toward doing both, at the moment.
Karl, thanks for the report
Senthil Kumaran added the comment:
David Karl -
I had been thinking on this. My understanding of the RFC implies that server
should reject when the headers contain the whitespace and I had a little
concern if the client library should feel free to cleanup a wrongly set
headers? Would it be
R. David Murray added the comment:
Good point. Seeing what curl does sounds like a good idea.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17322
___
Senthil Kumaran added the comment:
Looks like curl is sending the headers without removing spaces.
Check Raw here link here. (The link would probably be online a week)
http://requestb.in/1kfodmj1?inspect
$ curl --header X-MyHeader: 123 http://requestb.in/1kfodmj1
ok
$ curl --header
karl added the comment:
Hello,
So I tested a bit. The production rules defined by the specification are clear.
Spaces before and after are forbidden.
header-field = field-name : OWS field-value BWS
field-name = token
field-value= *( field-content / obs-fold )
Senthil Kumaran added the comment:
Oh wow. Thank you very much Karl for the care. I am having the same
inclination are you too, but determining a definite answer is really
helpful before going ahead into making the change.
--
___
Python tracker
Senthil Kumaran added the comment:
The curl example also suggest to think about pragamatic de-facto
stuff. Will removing the spaces cause any breakage? I can say for
sure. But if someone can think of it, it would be good for at least us
know.
--
___
karl added the comment:
OK. I'm inclined to think that we should both remove trailing and leading
spaces/tabs should be removed.
Reasons:
1. Production rules forbid them.
2. Trailing spaces
2.a Conformant servers will ignore with a 400 bad request (opportunity for
another bugs?)
2.b
R. David Murray added the comment:
It is a bug in the program, though, and not particularly in the client library.
As mentioned, it can even be useful for testing servers.
In the email package we faithfully reproduce such headers if they are passed
in. The only one we disallow is something
karl added the comment:
R. David Murray,
You are right it is not specific to the client library. HTTP headers are part
of the message (Request/Response) with both the same constraints. Constraints
are put on receivers (receiving a message) and senders (sending a message) of
the message
karl added the comment:
http://hg.python.org/cpython/file/3.3/Lib/urllib/request.py#l359
def add_header(self, key, val):
# useful for something like authentication
self.headers[key.capitalize()] = val
and http://hg.python.org/cpython/file/3.3/Lib/urllib/request.py#l271
in
karl added the comment:
I created 4 tests for testing trailing and leading spaces on
* add_unredirected_header()
* add_header()
and modified the functions.
Tests passed.
→ ./python.exe Lib/test/test_urllib2net.py
[…]
test_headers_with_spaces (__main__.OtherNetworkTests) ... ok
[…]
Changes by karl karl+pythonb...@la-grange.net:
--
title: urllib.request add_header() currently allows trailing spaces -
urllib.request add_header() currently allows trailing spaces (and other weird
stuff)
___
Python tracker rep...@bugs.python.org
karl added the comment:
Yet another one leading spaces :(
req = urllib.request.Request('http://www.example.com/')
req.header_items()
[]
req.add_header(' Foo3', 'Ooops')
req.header_items()
[(' foo3', 'Ooops')]
req.headers
{' foo3': 'Ooops'}
--
23 matches
Mail list logo
