[Web-SIG] HTTP header canonicalization?

[Ian Bicking]

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 
>> [1], not the State Management RFC [2]. See section 10.1.2 of [2] 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 
pretty common.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org