Open Bug 166786 Opened 22 years ago Updated 3 months ago

Can't save / view source POST query (e.g. ebay auction)

Categories

(Toolkit :: View Source, defect, P3)

Product:
Toolkit
Component:
View Source
Platform:
x86
Linux
Type:
defect

Tracking

()

People

(Reporter: BenB, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Shell script behind the Midwinter test case
387 bytes, text/plain
Details 
Setup:
- Mozilla 1.0.1
- Disk Cache 0KB
- Mem Cache 4MB

Reproducable: 100%

Reproduction:
1. Go to <http://www.recordstore.co.uk>
2. Enter search term in box at the top, hit Enter
3. Try to save the result page

Actual result:
Impossible.
- If I do Context menu|This Frame|Save Frame As..., I save the homepage.
- If I do Context menu|This Frame|Open Frame in New Tab or Show Only This Frame,
  I get the homepage.
- If I do View Source, I get a dialog asking me, if I want to resend the query.
If I confirm that, I get the results page in the View Source window, *rendered*
(not as HTML source)

Expected result:
*Neither* of these commands should *ever* trigger a network request. Just take
what's there, the DOM or a special mem cache or whatever. I should save / win in
other windows whatever I see in the initial frame.

Additional Comments:
- Anything the site or proxy sends is irrelevant for this bug being valid. Even
if the site says not to cache or to expire immediately, this must still work as
described.
- I am aware of bug 55583, but that's marked fixed. Seems like it isn't.
Also tested with Mozilla 1.1. Same result, with one exception: View Source (of
the frame) works as expected. As least I could finally save that page! (using
copy&paste)
> - Disk Cache 0KB

Dude.  You turned off the cache.  We do not store HTML documents in memory cache
unless they have the no-store cache-control header....

I think this falls in the category of "don't do stupid things" (though I should
note that some of the operations you described, like "show only this frame", do
not even properly access the cache.  So having a cache may not help there).

> You turned off the [disk] cache.

Irrelevant.

The page is being *displayed*. Disk cache is for stuff I visited 3 days ago.

In fact, I'd argue that this should work even with no cache at all, not even mem
cache.

> We do not store HTML documents in memory cache
> unless they have the no-store cache-control header....

That's another bug, then. I expect the mem cache be the same as the disk cache,
but only in mem instead of on disk.

> I think this falls in the category of "don't do stupid things"

Disabling disk cache is not stupid at all. There are good reasons for disabling
disk cache, e.g. disk fragmentation, local proxy, diskless workstation etc..
Disabling disk cache is the first thing I do with new profiles. But this bug
must not appear in this case.
> That's another bug, then.

Yes.  If you bother to search ("multi level cache" and such) you will even find it.


Confirmed on WinXP and Win2K, even with disk cache enabled.  This used to work
under 1.0.  It's a severely annoying bug when you're trying to develop a
form-heavy Web site.  I agree with the submitter -- doing a "view source" should
never, ever require hitting the server.

If setting no-cache on a document causes Mozilla to have to go back to the
server to view source, then as a naughty web site designer I can intentionally
make it a big pain for my Mozilla users to see the source of my pages.  (Think
one-time-only authentication tokens and <meta> tags to grant new tokens for
reloads.)  I don't think a browser should ever behave in such a way that a user
has to go to great lengths to review what the server has sent down the wire.
If this is happening with disk cache enabled, that's different.  We should be
ignoring things like no-cache for view-source.  Any test documents you could
point me to here?  I cannot reproduce the problem with
http://www.zbarsky.org:8000/~bzbarsky/sourcetest.html (which sets no-store on
the page, I should note).
<http://www.midwinter.com/cgi-bin/moztest>

Hit the button, then do a view source and notice that you get a different PID
than the one on the rendered page.  If you do a view source without hitting the
button, it works fine.

As a matter of fact, if you look at the PIDs you get back, there's a clue to
what might be going on; looks like when you view source on a POSTed page, the
browser tries to show you a copy of the most recent GET to the same URL, and if
there wasn't one already, it hits the server.  But there might be more to it
than that.
Steven, I can't reproduce the problem on that testcase with a trunk linux
build.. the PID I see in view-source is identical to what I see on the page...
Just downloaded the latest Windows nightly build (2002091014) and I'm still
seeing the problem.  Some more details on my config, in case they're relevant:
My disk cache is set to 50000KB and my memory cache to 4096KB.  Cache checking
frequency is set to "When the page is out of date."  Not using an HTTP proxy. 
I'm using the latest Multizilla build.
Multizilla?  The commented in bug 55583, comment 263 is also using multizilla...
Could you try a _non_-Multizilla build?  I'll go take a look at how multizilla
implements view-source...
This is multizilla's "view-source in a tab" feature?  If so, they're just doing
it wrong.  Hence the problem.
Aha, yes, this does seem to be Multizilla's fault.  If I uninstall it, I get the
right source from my test case.  I'll report this on their Bugzilla database.
This is already fixed in MultiZilla. I just forgot to commit my changes in our
cvs tree, so Raj (our webmaster) did a commit for me, but he didn't had the
latest update of multiviewsOverlay.js.
Compare bug 172429 (about ebay), which is similar in effects, but not symptoms.
Summary: Can't save / view source POST query → Can't save / view source POST query (e.g. ebay auction)
The design of File/Save as... and View Source are dependent on the cache.  If
the caches are too small or disabled, then the pages will have to be refetched.

The cache and HTTP have a mechanism designed to allow "pinning" items in the
cache so they don't get evicted until the current page is done with them, but it
will require clients of HTTP to support it.  See bug 72519.

Changing component to ViewSource.
Assignee: gordon → doron
Component: Networking: Cache → ViewSource
QA Contact: tever → pmac
Steven's moztest can be used also to see that saving the page triggers a new
POST request without any confirmation, at least on 1.2.1.

I think that the normal "resend POST data" warning should be shown if the POST
must be repeated to save the page. At least I would have needed it yeaterday.
I'm seeing this bug when I try to "View Source" on the result of a Bugzilla POST
(e.g. the page shown after changing a bug and committing). 

My disk cache is set to 50MB, and the page doesn't have an "Expires" header
(from the Page Info dialog), yet when I try to View Source, I get a popup saying
that the page has "expired from the cache", and that the POST will have to be
repeated (and it does, too).

Steps: Change a bug, hit Submit, and on the resultant page, try View Source.

(I'm also going to try it out immediately after I submit this add, to make sure
that this is not an installation-specific thing in Bugzilla itself..)

Yup, it did. It told me that the page contained POSTDATA that was expired from
the cache, and that it would have to re-post in order to View Source.

Running 1.4-rc1, by the way. And I don't think this has been fixed in rc2,
either (though I'm loath to update because of a by-now-well-known mailnews bug
in remembering View settings by account or newsgroup).
And this bug doesn't seem to be ViewSource-specific, either. If I navigate to
another page from the result-of-the-POST page, and hit Back, I get the same
warning. So something seems to be broken in the expires check in general..
Does it have no-cache or no-store pragmas?  (page info won't tell you that --
you have to look at the http headers)
"I am aware of bug 55583, but that's marked fixed. Seems like it isn't."

Either it was marked fixed in error, or the bug has come back.

The issue has cropped up in off-topic comments to bug 57724.  The testcase in
bug 57724 comment 113 is given as affecting Windows but not Linux.  But you
claim that the problem is in Linux.

That testcase and this one both work fine in 2003070708 (Mac OS X).  Could
someone please check a current nightly build in Windows and Linux?  This'll
determine if the problem's still there, and whether it's worth marking pp.

Apart from that, since this is a re-raising of an old bug, what do you experts
think should be done:

- reopen bug 55583 and dupe this one to it?
- dupe bug 55583 to this one?
- just leave it?

> Either it was marked fixed in error, or the bug has come back.

Bug 55583 covered the fact that view-source requested the source from the server
even if we had it in our cache.  That was a major problem.  That bug is fixed. 
Period.

This bug covers the fact that source for a page being viewed can expire from the
cache, which will force view-source to rerequest it from the server.  Totally
different issue.
Oops, my incomplete testing, view source works on the recordstore example but
save doesn't.

This is a matter of bug 40867, which is apparently fixed.  So I guess the save
function just needs wiring up to this fix.

Another absurdity: back/forward works (thank goodness for a browser that finally
behaves sensibly ITR) but Show Only This Frame and Open Frame in New Window/Tab
don't.  Maybe this is another bug....
I am running Mozilla1.4(Gecko/20030624) on a W2k machine.

I get the pop up window asking me to resend the POSTDATA 
using the View Page Source.

Go to

http://democam.mobotixserver.de/cgi-bin/store2rom

press the button, wait for the page to return and then do
right-click -> View Page Source.
Now a popup window will appear telling you that the "page you are trying
to view contains POSTDATA that has expired from cache". If I confirm the
source codes appears after a short while.

I've checked my mozilla settings: Memory and Disk Cache are enabled and
set to values > 0.

The difference to the usual configuration is, I am using a proxy (SQUID) on the
computer where the popup appears. Without proxy the popup window does not appear!

The HTTP Header of the page that comes from the proxy looks like:
HTTP/1.0 200 OK
Content-Type: text/html
Cache-Control: no-cache
X-Cache: MISS from firewall.mobotix.net
Proxy-Connection: close

If I access the page *without* proxy only the last two lines are
missing. That means, the cache-control message is always included and thus
it can not trigger this behaviour.

Hello again,

I can now access the testpage from my computer without the proxy 
(earlier I had to use a different computer that had a direct
connection).

Even without the proxy the popup appears wanting to resend the POSTDATA.

Darn, it may have to do with my local configuration but I have no idea
what it might be. Any hints are welcome! 

What files do I have to delete do get a clean new installation of mozilla?
Great! Uninstalling Mozilla, deleting the Mozilla directory in my user folder
and reinstalling it did fix the problem. Maybe it was because I had all
the Mozilla milestone versions since 1.0 installed on that computer.

wfm Mozilla 1.4: View Page Source does not ask to resend POSTDATA. 

Sorry for wasting your bandwidth.

Cheers,
Daniel
Germany




*** Bug 212650 has been marked as a duplicate of this bug. ***
Hello everybody,

I am still using Mozilla 1.4 and did not touch about:config but
the "resend the data" window is back. :-(

I've just checked the testcase in comment #26.

It's a bummer.

I'm seeing this on
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030820 Mozilla
Firebird/0.6.1+

I post to a(n error) page (of mine).. view source... "this page contains POST
that has expired...", I'd post a comment for bug 40867 if not for Hixie's
comment 321 there.  (Ps. could not reproduce testcase on comment 26, Daniel)
Error pages are bug 212650, not this bug.
sorry, I didn't mean an error page.

It happened to occur on a coldfusion page with a script error (and wasn't
forwarded or handled in any way).

In any case, to the browser, it would have seemed like any other page.
A testcase that is publically accessible would be nice, then.
http://www.aocsolutions.com/postThrow.cfm
(temporary page.. I don't have a private coldfusion server of my own)

1. Click on 'try me'
2. Land on postCatch.cfm, observe script error (in between body tags with no
other filler but the bad script)
3. Right click.. View Source
4. Observe "The page you are trying to view contains POSTDATA..."
Um.  That page is in fact a server error page returned with HTTP status code 
500.  So that's bug 212650, not this bug.
*** Bug 213099 has been marked as a duplicate of this bug. ***
*** Bug 246858 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Blocks: 288462
Simple test: log in to bugzilla.mozilla.org.
Then view source. Firefox reports the data. Why?!?
(In reply to comment #39)
> Simple test: log in to bugzilla.mozilla.org.
> Then view source. Firefox reports the data. Why?!?

I don't know what you mean with "Firefox reports the data". 

If I log in to bugzilla.mozilla.org and then view source, I observe the pop-up window containing the message "The page you are trying to view contains POSTDATA...". No source code is displayed.


Looks to me like a typo for "reposts".
(In reply to comment #41)
> Looks to me like a typo for "reposts".

It is a typo. I meant "reposts".

Source code (Ctrl-U) is shown for me with user agent "Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)"
Assignee: doronr → mrbkap
QA Contact: pmac → doronr
For any page which is visible, "Save As", "Print", "View Source", "Open Frame In New Tab" and similar functions should never, under any circumstance, open a network connection.  The viewed pages must be stored raw in RAM or disk cache, any other method is faulty.  HTTP headers or meta tags specifying not to cache a page should have no bearing on the user's ability to use the currently viewed page(s).
Assignee: mrbkap → nobody
QA Contact: doronr → view-source
Is this still an issue in SeaMonkey 2.x?
SeaMonkey trunk is now using toolkit viewsource.
Product: SeaMonkey → Toolkit
QA Contact: view-source → view.source
(In reply to comment #2)
> > - Disk Cache 0KB
> 
> Dude.  You turned off the cache.  We do not store HTML documents in memory cache
> unless they have the no-store cache-control header....


the page is in the memory, why it should get the page source from the cache? this is irrelevant. show it from the memory.

the same problem is for the images, i see a image in my window (firefox), i want to save it, it starts to download again! 6mb, i have to wait 3 minutes again, but it is already in my computer.
(In reply to comment #47)
> the same problem is for the images, i see a image in my window (firefox), i
> want to save it, it starts to download again! 6mb, i have to wait 3 minutes
> again, but it is already in my computer.

if you settings are

(In reply to comment #0)
> - Disk Cache 0KB
> - Mem Cache 4MB

how do you expect 6MB to be cached as is exceeds the cache size.
i don't expect it to be cached, if i see the image it is already in my memory, get the image from there.
(In reply to comment #49)
> i don't expect it to be cached, if i see the image it is already in my memory,
> get the image from there.

Only it might as well be in the memory of your graphics card. Don't expect it to be retrieved from there. 

Why not try with higher cache limits instead?
Daniel Krebs, the cache is for things I come back to, it's an optimization only, by definition. The cache must never affect functionality. Pages that are currently in display should of course be in memory.

There is a difference between the page we got from the network, and the page currently displayed. It's arguable what the user wants when he Saves on disk or does View Source. If a copy of the original page is needed for that, though, then it must be kept, not matter the cache settings. It's not a cache, it's what I work with currently.
s/Krebs/Kabs/

> > - Mem Cache 4MB
> how do you expect 6MB to be cached as is exceeds the cache size.

FYI, you mixed up people here (as I did :)). *I* had 4 MB mem cache, in 2002.
But that's irrelevant.
(In reply to comment #51)
> the cache is for things I come back to, it's an optimization
> only, by definition. The cache must never affect functionality. Pages that are
> currently in display should of course be in memory.

I think you are right. But by a different reasoning: Any HTTP response can request not to be cached. If saving HTTP data (web page, images, ...) would require caching, the user could loose this functionality if HTTP response requested to avoid caching.
Again, this is not a cache. A cache is used to open the page *again*. When I save it, I do not open it again, I save the page I *currently* view. It's part of the working memory needed to work with the displayed page.

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

The severity field is not set for this bug.
:Honza, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(odvarko)

Does anyone have a test page that can be used to reproduce this issue?

Honza

Severity: -- → S3
Flags: needinfo?(odvarko)
Priority: -- → P3

It should be easy to create a dedicated testcase with node.js and Express, but I don't have the time to create it, sorry. You would make the HTML page a result of a POST request, and for good measure, set all possible no-cache headers, Expires etc.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: