[Web-SIG] HTTP header canonicalization?
ianb at colorstudy.com
Mon Aug 23 00:59:04 CEST 2004
Phillip J. Eby wrote:
> At 03:10 PM 8/22/04 -0700, Mark Nottingham wrote:
>> The only problem I'm aware of is Set-Cookie, which can have an
>> unquoted expires date in it; e.g.,
>> Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday,
>> 09-Nov-99 23:12:40 GMT
>> If you have two of these, the comma after the day (here, "Wednesday")
>> makes parsing problematic.
>> Note that this is only specified in the original netscape cookie spec
>> , not the State Management RFC . See section 10.1.2 of  for
>> more discussion of this issue.
>> So, you *shouldn't* see these, especially since WSGI is about the
>> server side. All the same, I'll ask around to see how often they're
>> still seen in the wild.
> Unfortunately, this seems like something that's awfully likely to be
> present in Python frameworks "in the wild".
I don't know if that's true. Most (all?) frameworks have an explicit
way of setting cookies, rather than having applications generate
Set-Cookie headers on their own. Since they have to be modified for
WSGI, changing this might not be so bad. Though right now the standard
Cookie class does create multiple headers.
Many (most?) frameworks also use a dictionary representation for headers
as well, sometimes with distinct methods for adding and setting headers
(where adding creates a list of values, but only if it has to). Several
independent response implementations seem to work this way, so it's
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG