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 karlcow
Recipients karlcow, orsenthil, r.david.murray
Date 2013-03-03.19:14:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1362338068.52.0.933869048026.issue17322@psf.upfronthosting.co.za>
In-reply-to
Content
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 )
    field-content  = *( HTAB / SP / VCHAR / obs-text )
    obs-fold       = CRLF ( SP / HTAB )
                   ; obsolete line folding
                   ; see Section 3.2.4

and 

  token = 1*tchar

and tchar as 

  tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
   "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA

Here are the production rules for HTTP headers for messages (so both Request and Responses). 

You can have funky headers, I guess that would be interesting to add to the urllib tests too. Basically to have something in the library, which check if header contains the tchar characters and sends back a warning of exception when not part of it.

curl has a bug too, IMHO. Though, one might argue that it is practical for testing bugs. :)

On the side of parsing it's clear for the trailing space but unknown for the leading spaces. I sent a long email explaining the issue to the HTTP WG.

See http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1166.html

Let's see what will be the answers
History
Date User Action Args
2013-03-03 19:14:28karlcowsetrecipients: + karlcow, orsenthil, r.david.murray
2013-03-03 19:14:28karlcowsetmessageid: <1362338068.52.0.933869048026.issue17322@psf.upfronthosting.co.za>
2013-03-03 19:14:28karlcowlinkissue17322 messages
2013-03-03 19:14:28karlcowcreate