Open
Bug 166786
Opened 22 years ago
Updated 2 years ago
Can't save / view source POST query (e.g. ebay auction)
Categories
(Toolkit :: View Source, defect)
Tracking
()
NEW
People
(Reporter: BenB, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
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.
Reporter | ||
Comment 1•22 years ago
|
||
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)
Comment 2•22 years ago
|
||
> - 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).
Reporter | ||
Comment 3•22 years ago
|
||
> 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.
Comment 4•22 years ago
|
||
> That's another bug, then.
Yes. If you bother to search ("multi level cache" and such) you will even find it.
Comment 5•22 years ago
|
||
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.
Comment 6•22 years ago
|
||
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).
Comment 7•22 years ago
|
||
<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.
Comment 8•22 years ago
|
||
Comment 9•22 years ago
|
||
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...
Comment 10•22 years ago
|
||
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.
Comment 11•22 years ago
|
||
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...
Comment 12•22 years ago
|
||
This is multizilla's "view-source in a tab" feature? If so, they're just doing
it wrong. Hence the problem.
Comment 13•22 years ago
|
||
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.
Comment 14•22 years ago
|
||
Bug 2065 filed against MultiZilla:
http://mozdev.org/bugs/show_bug.cgi?id=2065
Comment 15•22 years ago
|
||
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.
Reporter | ||
Comment 16•22 years ago
|
||
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)
Comment 17•22 years ago
|
||
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
Comment 18•22 years ago
|
||
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.
Comment 19•21 years ago
|
||
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..)
Comment 20•21 years ago
|
||
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).
Comment 21•21 years ago
|
||
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..
Comment 22•21 years ago
|
||
Does it have no-cache or no-store pragmas? (page info won't tell you that --
you have to look at the http headers)
Comment 23•21 years ago
|
||
"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?
Comment 24•21 years ago
|
||
> 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.
Comment 25•21 years ago
|
||
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....
Comment 26•21 years ago
|
||
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.
Comment 27•21 years ago
|
||
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?
Comment 28•21 years ago
|
||
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
Comment 29•21 years ago
|
||
*** Bug 212650 has been marked as a duplicate of this bug. ***
Comment 30•21 years ago
|
||
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.
Comment 31•21 years ago
|
||
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)
Comment 32•21 years ago
|
||
Error pages are bug 212650, not this bug.
Comment 33•21 years ago
|
||
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.
Comment 34•21 years ago
|
||
A testcase that is publically accessible would be nice, then.
Comment 35•21 years ago
|
||
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..."
Comment 36•21 years ago
|
||
Um. That page is in fact a server error page returned with HTTP status code
500. So that's bug 212650, not this bug.
Comment 37•21 years ago
|
||
*** Bug 213099 has been marked as a duplicate of this bug. ***
Comment 38•20 years ago
|
||
*** Bug 246858 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 39•17 years ago
|
||
Simple test: log in to bugzilla.mozilla.org.
Then view source. Firefox reports the data. Why?!?
Comment 40•17 years ago
|
||
(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.
Comment 41•17 years ago
|
||
Looks to me like a typo for "reposts".
Comment 42•17 years ago
|
||
(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)"
Updated•16 years ago
|
Assignee: doronr → mrbkap
QA Contact: pmac → doronr
Comment 43•16 years ago
|
||
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).
Updated•15 years ago
|
Assignee: mrbkap → nobody
QA Contact: doronr → view-source
Comment 44•15 years ago
|
||
Is this still an issue in SeaMonkey 2.x?
Comment 45•15 years ago
|
||
SeaMonkey trunk is now using toolkit viewsource.
Product: SeaMonkey → Toolkit
QA Contact: view-source → view.source
Comment 47•14 years ago
|
||
(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.
Comment 48•14 years ago
|
||
(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.
Comment 49•14 years ago
|
||
i don't expect it to be cached, if i see the image it is already in my memory, get the image from there.
Comment 50•14 years ago
|
||
(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?
Reporter | ||
Comment 51•14 years ago
|
||
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.
Reporter | ||
Comment 52•14 years ago
|
||
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.
Comment 53•14 years ago
|
||
(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.
Reporter | ||
Comment 54•14 years ago
|
||
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.
Comment 56•2 years ago
|
||
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 → --
You need to log in
before you can comment on or make changes to this bug.
Description
•