116167 - "Save Image" uses POST method

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect, P2)

Description

[Kunihiko Aizawa]

Reproducible BuildID:    2001121219 and later

Reproducible situation:
The image is on a web page (mostly CGI output) which is opened by POST method.

Bug details:
In this situation, and when we use "Save Image" of context menu, mozilla
doesn't save the image correctly. File is created on local disk, but content
of it is not image data but html text for http error [405 Method Not Allowed]
from server. This mentions that mozilla uses wrong POST to get the image under
the situation.
I think this is one of "Save Image" bugs relaterd to bug 11632.


Reproducible: Always
Steps to Reproduce:
1.Go to the URL.
2.Push submit button on the page to open next page by POST method.
3.Save image on the 2nd page by using "Save Image..." of context menu.

Actual Results:  The saved image file is broken, contains incorrect data.

Expected Results:  Save the image as it is.

Comment 1

[Kunihiko Aizawa]

Sorry, I didn't write about buildID and platform.
I confirm this symptom on Win32:2001121803, OS2:2001121819, OS2:2001121219.
OS2:2001121111 does not have this symptom.

Comment 2

[Boris Zbarsky [:bzbarsky]]

To ben.  We should really pull such things from cache.... and use the right 
postdata.

Comment 3

[Tom Mraz]

Seeing this with the Linux 2001121808 nightly too.
This is definitely a major regression.
Please consider fixing it in the 0.9.7 release.

Note that the request for the saved image shouldn't use the POST request at all
because it should be loaded with a GET (or from the cache) because it's simply
linked on the page which is generated on the POST request.

There is something pretty broken in the new Save Page/Image logic.

Comment 4

[Tom Mraz]

There is simple workaround so if it doesn't catch the 0.9.7 train please at
least relnote it.

Use Viev Image first then Save Image. Then Mozilla saves the image fine.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch to fix

only use postData when saving if we're saving a document (when it makes sense)
not objects for which postdata have no relevance (images, links, etc)

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

Fixed. Patch w/analysis in bug 120174. 

Comment 7

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.01.23.0x comm bits on linux rh7.2, win2k and mac os
10.1.2. Kunihiko, thanks for the excellent test case!

Comment 8

[Jonas Petersson]

It seems that there is a variation of this bug still around. Here is what I see:

* Submit a form as a POST to a URL which produces an image - lets say that this
URL which draw the string "POST" in the image if posted and "GET" if not.

* Now try to save this image to disk (Save image as... for example)

* Mozilla will now save an image containing "GET" after having perform first a
HAD request and then a GET request to the URL.

Pretty broken IMHO.

BTW: I've used Debian 1.4-0jds2 for my own experiements, but also verified it
with latest Firebird. Interesting to note is that this problem seems to exist in
Netscape 4.77 too - but there "Save as..." from the "File" menu at least works.

I have a rather complicated page in Swedish where this can be seen - let me know
if you need it or a simplified one.

Comment 9

[Boris Zbarsky [:bzbarsky]]

"Save Image As" just saves the image at the image URL.  That option should not
even be enabled on image-only pages; the fact that it is would be a bug separate
from this one.

Comment 10

[Jonas Petersson]

Possibly true (though again, it is around in most other browsers that I know
of), but then "Save as..." from the "File" menu is still broken in a way that
seems exceedingly related to this bug (GET/POST mixup during Save, BTW: the
"HAD" should have been "HEAD" in my first note, but I'm sure you guessed that).

In my humble opinion, a "Save as..." (in particular for a server generated
image) should work against the cache unless the server explicitly has forbidden
it - I know my server hasn't.

I don't mind creating a brand new bug for this if you insist though. Please confirm.

Comment 11

[Boris Zbarsky [:bzbarsky]]

See bug 160454 

Comment 12

[Jonas Petersson]

Right, comment no 5 in that bug indeed describes what I experience even though
the actual bug is about HEAD (which in itself isn't a major problem in my case).
Still, it doesn't look like much is happening about solving the issue - I guess
I've have to recommend my users to run IE or NS 4.7 for now, then...