Re: [Chicken-users] http cookie order
Thanks for a very informative analysis. Of course this whole problem only cropped up because we Schemers like to build up lists by consing new elements to the front. I would probably have included a reverse in the result of the let loop without thinking, but unless you have reason to suspect that attribute order will matter somewhere down the line, that's just wasted CPU cycles and wasted consing. Of course, then somebody comes along and writes a hack to update the cookie attribute.. :) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http cookie order
On Mon, Mar 31, 2008 at 1:40 PM, Tony Sidaway [EMAIL PROTECTED] wrote: Thanks for a very informative analysis. Of course this whole problem only cropped up because we Schemers like to build up lists by consing new elements to the front. I would probably have included a reverse in the result of the let loop without thinking, I think I'm wired the same way. Typing (if (null? lst) (reverse acc) ...) is the path of least resistance! but unless you have reason to suspect that attribute order will matter somewhere down the line, that's just wasted CPU cycles and wasted consing. I don't think I'd worry much about the consing: there are rarely many attributes in a request, and minor GC would deal with the garbage quickly and efficiently. It's worth the cost in order to make the attribute-list more correct, and Drake has dug up proof that ordering is significant in the spec. Of course, then somebody comes along and writes a hack to update the cookie attribute.. :) Let's hope they do it with (set-cdr!) and all is well! Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http cookie order
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
Re: [Chicken-users] http cookie order
Quoth Graham Fawcett [EMAIL PROTECTED], on 2008-03-28 09:59:16 -0400: 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. FWIW, from RFC 2616 (HTTP/1.1), section 4.2: | Multiple message-header fields with the same field-name MAY be | present in a message if and only if the entire field-value for that | header field is defined as a comma-separated list [i.e., #(values)]. | [...] The order in which header fields with the same field-name are | received is therefore significant to the interpretation of the | combined field value, and thus a proxy MUST NOT change the order of | these field values when a message is forwarded. From RFC 2109 (HTTP State Management Mechanism), section 4.3.3: | If a user agent receives a Set-Cookie response header whose NAME is | the same as a pre-existing cookie, and whose Domain and Path | attribute values exactly (string) match those of a pre-existing | cookie, the new cookie supersedes the old. It's not entirely clear whether pre-existing means from a previous request or not. A Web search does not turn up much discussion on the matter. A previous preliminary specification, http://wp.netscape.com/newsref/std/cookie_spec.html, writes with the latest instance taking precedence which is also somewhat ambiguous in that latest may or may not mean latest within the same response. My interpretation of this is: - Forwarders are not permitted to rearrange multiple Set-Cookie headers. HTTP client and server libraries have the same constraint. - Origin servers should not generate multiple Set-Cookie headers in the same response for the same (name, domain, path) tuple, since it is not clear what one should do with them. - Clients should interpret Set-Cookie headers in the order they are received, partly because it's a more constrained interpretation of the term pre-existing in the spec, and partly due to rude-ish websites that will return ambiguous responses and expect that interpretation. (I do not know of any site that expects a different interpretation of multiple cookies overwriting each other in the same response.) (RFC 2109 is also supposedly obsoleted by RFC 2965, but that describes the behavior of Set-Cookie2 headers, not Set-Cookie headers, and it doesn't seem any clearer.) --- Drake Wilson ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http cookie order
On Fri, Mar 28, 2008 at 8:31 PM, Drake Wilson [EMAIL PROTECTED] wrote: [RFC excerpts snipped] My interpretation of this is: - Forwarders are not permitted to rearrange multiple Set-Cookie headers. HTTP client and server libraries have the same constraint. - Origin servers should not generate multiple Set-Cookie headers in the same response for the same (name, domain, path) tuple, since it is not clear what one should do with them. - Clients should interpret Set-Cookie headers in the order they are received, partly because it's a more constrained interpretation of the term pre-existing in the spec, and partly due to rude-ish websites that will return ambiguous responses and expect that interpretation. (I do not know of any site that expects a different interpretation of multiple cookies overwriting each other in the same response.) Excellent analysis, Drake. I think your interpretation is on the money. (RFC 2109 is also supposedly obsoleted by RFC 2965, but that describes the behavior of Set-Cookie2 headers, not Set-Cookie headers, and it doesn't seem any clearer.) Yes, I find that odd as well. :-) Thanks, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
