On Thu, Mar 27, 2008 at 9:07 PM, Tony Sidaway <[EMAIL PROTECTED]> wrote: > Using http.egg to write a bot that has to login to a ubb forum, I > discovered that the cookie processing order of that egg resulted in > login failure. When I tweaked http:read-request-attributes to > reverse the order of the attributes it returned, all was well. > > This is because in reply to a successful login the ubb server sends a > sequence of set-cookie headers, one of which is something like > "ubbt_myid=deleted" (presumably to end any previous session) while a > later header contains a cookie that looks something like > "ubbt_myid=26" signifying the id corresponding to the username. > > Processing the cookies in the wrong order results in the Cookie > attribute of the http-request object being set to contain > "ubbt_myid=deleted", destroying the session login data on the client > side and effectively ending the session.
It's a bit risky of the UBB server to send two Set-Cookies with the same cookie name, without giving one precedence by specifying a more specific path. RFC2109 allows for multiple Set-Cookies, but it also warns that "an intervening gateway could fold multiple such headers into a single header". Since "folding" is undefined, there's no way the origin server can guarantee the sequence of the cookies in the received header. If the two cookies have different path precedence, that's a different matter: effectively they are two different cookies. I suppose it makes sense to retain the headers in the order they were received from the server, but gateway meddling could lead to unpredictable results in this particular case. Just my two cents, Graham _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
