Enabling cookies causes callback links to incorrectly redirect in Firefox

I've logged a bug: http://code.google.com/p/pier/issues/detail?id=132 The text of the bug is: Steps to recreate the bug: 1) Download the recent build of Pier 2 - http://hudson.lukas-renggli.ch/job/Pier%202/ - this bug is not present in Pier with Seaside 2.8 2) In a workspace execute the following: PREventDistribution register. WAAdmin defaultDispatcher defaultHandler preferenceAt: #useCookies put: true. (PRPathLookup start: (PRKernel instances anyOne) root path: '/call') contents: 'In Firefox, try clicking on the counter +counter+'. (PRPathLookup start: (PRKernel instances anyOne) root path: '/call') addChild: ( (PRComponent named: 'counter') componentClass: WACounter; yourself) 3) Within Firefox (I'm using 3.16.13) browse to http://localhost:8080/pier/call - you should be on the "Call for Contributions" page into which the above script embeds the standard Seaside counter component in the page. 4) Try clicking on the "++" or "--" links a couple of times and you'll find yourself taken to http://localhost:8080/pier/dates and rather than modifying the counter value. Here's my understanding of the bug: 1) Amongst other metadata Pier adds the following to the header: <link href="/pier/dates" rel="next"> 2) In Firefox when cookies are enabled, the <link rel="next"> causes firefox to issue at least two requests for each page; the first request for the url specified, the second for the url specified in the href of the <link rel="next">. Note this second request is not visible in firebug (I added request logging to WAComancheRequestConverter). In Safari or Chrome, I haven't seen any additional requests and so the problem does not appear. 3) The second request confuses the callback hander Unfortunately my understanding of how the callback handler should work is limiting my ability to fix the bug. Any thoughts?