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. I guess I'd recommend that we incorporate my tweak to http:read-request-attributes into the egg, but thought it best to circulate the matter widely first. Is there any reason why the attributes should be retained in the current order (legacy code that depends on the reversed order, perhaps?) If so, I guess the http:extract-cookies procedure could simply reverse the order of the set-cookie attributes before processing them. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
