Bug Demonstration Steps:

  1. Page 1: Load the operabug.html page describing the bug. Headers "Pragma: no-cache" and "Cache-Control: no-cache" are sent to prevent browser caching of this page. No cookies are set at this point.
  2. Page 2: Load the operabug2.html page, which will present a simple web form. Again the same cache-prevention headers will be sent. No cookies are set yet. The form must be submitted via the POST method.
  3. Step 3: The operabug2.html page will be loaded a second time to process the POST from the form submission from step 2. Once more, cache-prevention headers will be sent. However, instead of returning an actual result page, the response to the POST form submittion will be a 302 redirect back to the operabug.html page. This step WILL SET A COOKIE valid for the entire web site. If cookies are enabled in the browser, and if there are no browser cookie-handling bugs, the page loaded in the next step--reloaded actually, since the browser has seen that page before, but due to no-cache headers, the browser should have to reload it, this time sending the cookie set here in Step 3.
  4. Page 4: Load the operabug.html page a second time, following the above step's 302 redirect, which simultaneously set a cookie. If that cookie is correctly sent back to the web server, this text will be green.

Next Step:

Load page #2 (step 2) by clicking on this link.

Please note that if you have ALREADY clicked the bug demonstration Test My Browser button, then YOUR BROWSER IS BROKEN!

Opera 9 Bugs:

I've tested this behavior with Opera 9 on Windows XP. Opera doesn't send the cookie set during the 302 redirect to the page redirected to. All other browsers I've tested DO work correctly. After clicking on the Test My Browser button in Opera and the cookie failing to be sent, if the user manually reloads the page, Opera will then correctly send the cookie. The cookie IS set in Opera, Opera just fails to send it. This breaks many web sites that use cookies to let users login. It makes those sites (which require login) utterly unusable in Opera.

To be sure this was an Opera browser issue and NOT a web server or upstream web cache issue, I used Ethereal to sniff the network traffic directly between the web client and the web server (there were no proxies or caches between the two). Sure enough, the HTTP re-request for the initial page DID correctly follow the 302 redirect, and DID correctly make a re-request (thus honoring the "no-cache" directives sent on the first load of that page), but missing was the cookie header even though the network sniff showed a valid cookie was sent to the browser as part of the 302 redirect. Subsequent checking in the Opera 9 browser proved that Opera DID have the cookie. It just didn't send it even though the domain and path and expiration time on the cookie SHOULD HAVE CAUSED THE BROWSER TO SEND THE COOKIE!

Further testing with Opera reveals that this bug ONLY APPEARS if you have the "Accept only cookies from the site I visit" selected in the "Advanced" preferences section under "Cookies". If you instead choose "Accept cookies", there is no bug. THIS IS STILL A BUG WITH OPERA, however, because www.adg.us (this web site) IS the site I visit using Opera, and Opera DOES ACCEPT the cookie (which matches the preferences setting), but Opera DOES NOT SEND THE COOKIE CONSISTENTLY.

The Bug Is Fixed In Opera 9.10

Congratulations, Opera! The bug has been fixed based on testing Opera version 9.10 on both Windows XP and Mac OS X. Thanks, Opera team!

PHP Source of This Test