[wp-trac] [WordPress Trac] #19922: Cookie urlencoding in getHeaderValue method of WP_Http_Cookie confuses servers

[WordPress Trac]

#19922: Cookie urlencoding in getHeaderValue method of WP_Http_Cookie confuses
servers
------------------------------------+------------------------------
 Reporter:  pw201                   |       Owner:  westi
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  HTTP                    |     Version:  2.8
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------------------

Comment (by pw201):

 The right thing to do with current servers and browsers (which as the
 Stack Overflow guy says, don't follow the RFCs) is to leave the data alone
 as much as you can: that means the urldecode in the constructor for
 WP_Http_Cookie and the urlencode on the output side should go, to my mind.
 If someone manually constructs a cookie with illegal characters in, you
 get to decide what you do with those, but that's it (and in those cases,
 what some browsers do is use Unicode encodings: nobody does urlencoding).

 Things which currently break in the typical situation where the server
 sets cookies with the Set-Cookie header:

 * if a server sets a cookie like "1234://", the urldecode will leave that
 alone, and the encode will mess with the colons and slashes, so you'll end
 up sending the server something different from what it gave you. (This one
 also breaks when you build the cookie by hand with data from another
 source, which is what happens in the LJ API case).

 * if a server sets a cookie like "%41", the urldecode will turn that into
 "A", and the encode will leave it alone, again meaning you send the server
 something other than what it gave you.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19922#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software