It has almost been 12 years since we all had to worry about the Y2K bug right ? Well you'd think. Over the past few weeks I have been bothered by a problem with session management in one of the apps that I'm writing. I couldn't figure out why stuff was behaving so unexpectedly. At some point the hints became clearer and clearer that the dated cookies of the session were for some reason not being expired. The iOS URLConnection and the android http lib seemed to continue to send them along to the server after logging out. This was hard to confirm though, because both platforms hide the Cookie header from you when you make the request, the connection was https and I didn't have physical access to the server.
It made no sense however that iOS would have a fundamental Cookie management bug. So I build a small server and started testing cookie management on the iPhone. Everything looked just fine. Then I decided that I would copy the actual cookies the server was sending to the clients. I could get these values, because the Set-Cookie headers from the response (unlike the actual Cookie header in the requests) was visible. So I switch the values of my test server to the actual values from the server and suddenly I was able to reproduce the problem. The Set-Cookie that was supposed to expire the cookie seemed to turn the cookie into an undated cookie (so scoped to the session of the client instance).
I'm switching back to my old values and stuff starts working again. Again I copy the original server values. I select the text and suddenly I notice it.... Expires=Sat, 01-Jan-00 00:00:00 GMT; No... that can't be it. Could it ? I switch my test server to issue the year 1970 instead. Poof, suddenly it works. So first of all, 12 years after 2000 there is still a server sending a broken date format. And two, it seems the Y2K parsing support in iOS is broken. Experimentation shows that iOS can only parse double digit years in cookies between 70 and 99. So any double digit year before 1970 (epoch) cannot be converted into an actual year. And what happens if the date cannot be parsed ? Then the date is removed from the cookie altogether, and your cookie becomes a session cookie :D
It made no sense however that iOS would have a fundamental Cookie management bug. So I build a small server and started testing cookie management on the iPhone. Everything looked just fine. Then I decided that I would copy the actual cookies the server was sending to the clients. I could get these values, because the Set-Cookie headers from the response (unlike the actual Cookie header in the requests) was visible. So I switch the values of my test server to the actual values from the server and suddenly I was able to reproduce the problem. The Set-Cookie that was supposed to expire the cookie seemed to turn the cookie into an undated cookie (so scoped to the session of the client instance).
I'm switching back to my old values and stuff starts working again. Again I copy the original server values. I select the text and suddenly I notice it.... Expires=Sat, 01-Jan-00 00:00:00 GMT; No... that can't be it. Could it ? I switch my test server to issue the year 1970 instead. Poof, suddenly it works. So first of all, 12 years after 2000 there is still a server sending a broken date format. And two, it seems the Y2K parsing support in iOS is broken. Experimentation shows that iOS can only parse double digit years in cookies between 70 and 99. So any double digit year before 1970 (epoch) cannot be converted into an actual year. And what happens if the date cannot be parsed ? Then the date is removed from the cookie altogether, and your cookie becomes a session cookie :D
Comments
Post a Comment