Closed Bug 475542 Opened 16 years ago Closed 15 years ago

history/cache problem with view page source issues a GET command on an already POST-ed form

Categories

(Toolkit :: View Source, defect, P2)

1.9.1 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: stanley.appel, Assigned: cbartley)

References

()

Details

(Keywords: fixed1.9.1, regression)

Attachments

(1 file)

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
Blocks: 17612
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Assignee: nobody → cbartley
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
Attachment #359372 - Flags: review?(gavin.sharp)
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!
Flags: wanted1.9.1?
Attachment #359372 - Flags: review?(gavin.sharp) → review+
Keywords: checkin-needed
Flags: blocking1.9.1?
Priority: -- → P3
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: regression
Priority: P3 → P2
http://hg.mozilla.org/mozilla-central/rev/c64326e2fc59
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [1.9.1 checkin-needed]
Target Milestone: --- → mozilla1.9.2a1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6fea71385ca2
Flags: wanted1.9.1?
Whiteboard: [1.9.1 checkin-needed]
Version: Trunk → 1.9.1 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: