User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090126 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090126 Shiretoko/3.1b3pre Bug 469302 fixed the view source problem on already POST-ed forms. But here is a more hidden problem. If the source code contains a link to another file, e.g. a css file, and you click on it it loads this .css file. But when you use backspace to go back to the original page it does a GET on the server and does not load the page from local cache. Reproducible: Always Steps to Reproduce: 1. goto http://www.stappel.com/test.php 2. hit submit 3. do view source, it will show: Request type: POST 4. click on the link to "test.css", .css page is shown. 5. now hit backspace Actual Results: Request type: GET Expected Results: Request type: POST

The view source code now copies the cache key from the "page descriptor" to the new history entry. In hindsight this seems like an obvious thing to do. At least it's obvious once you realize that the "page descriptor" is another history entry, something that was not apparent in the original code. I find it a little bit surprising that this code worked for any case (i.e. GET but not POST). Here's what I think was going on: Cache keys for a page retrieved from a URL with GET seem to be just the URL itself. Cache keys for the same page as resulting from a POST typically have a numeric ID as well as the URL. When we created a history entry without a cache key, one would be created automatically using just the URL. So even without an explicit cache key, pages retrieved by GET were found in the cache. When the source page was the result of a POST, the automatically generated cache key didn't match -- it would still refer to the page returned by GET.

verified patch on the 1.9.1 branch and the correct page source is shown. even after a large amount of visits to other pages. nice work!