subbu.org

Here is a sequence illustrating how cookies can make GET requests short-lived and useless.

Using a modern browser, through a company’s careers page, I went to a job search site, filled in a search form, and searched for some jobs. There was no registration involved, and I was visiting this for the first time. I browsed through the search results, clicked on a few job listings, and emailed links to some of those to someone else. That other person clicked on those links, and got back this page below.

This is not an obscure site. Per Alexa, this specific site is listed among the top three most popular job search sites in US. So, a number of users must have experienced what this person experienced.

The interesting thing about the link I emailed was that, it seemed to have all the information required to fetch the Job posting. For instance, each link had a query parameter "jobid" which was unique among the results I got. So, I expected the code behind the URL to be able to fetch the job detail and construct a page for me, but this did not happen.

Given that the Job ID is part of the URL and that each link was submitted through GET, the author of this particular piece of functionality must have designed it correctly to be idempotent and replayable. But somewhere underneath, the site is creating a cookie or a session when I first visited the site, and is expecting it back on all future requests. And wget confirms it.

302 Object moved
Location: cim_NoBrandError.asp?ErrMsg=NoCookie

This explains it. When the career’s page transferred me to this job search site, the job search site must have set a cookie with some ID related to the referrer site, and must be expecting it back on each search result generated. The net result is that this cookie check is making perfectly valid replayable URL short-lived. There are legitimate cases when you want to make GET requests short-lived, e.g. in a banking application, but this specific site does not meet that criteria.