119132 - after a POST Browser issues another GET request if content-type is image/jpeg

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Christian Biskup]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221 on Win NT 4 / SP6

HTML form does a POST request, server returns an content-type image/jpeg.
Instead of displaying the image, the browser issues a GET request to the same URL.

It does not happen if
- HTML page does a GET request instead of POST
- HTML page does a POST request and the server returns text/plain, text/html:
data is displayed correctly, no additional GET request

- Content-type is audio/whatever, application/octet-stream: 
browser brings up the what-should-i-do dialog and does not issue the GET request.

It does happen with image/gif and image/pjpeg (and probably with any other
image/* type?)

The form fails with Netscape Communicator 6.1, 6.2, (Windows NT), too
The form works with Netscape 4.7x, IE 5, 6 (Windows).

The form works on Netscape 6.1 if content-type is set to video/quicktime because
the quicktime plugin gets the control and displays the image.

Comment 1

[Olav Vitters]

Reporter: Can you give an URL which demonstrates this problem?

Comment 2

[Olav Vitters]

Adding testcase URL. It submits to index2.php. That php file returns a image/png
with "GET" if the request method was GET and "POST" if the method was POST.
Using Linux 2002010921 I see the "GET" image.

A sniffer reveals that Mozilla first does a POST and then a GET.

Moving to Networking: HTTP and confirming.

Comment 3

[Olav Vitters]

somewhat related: bug 72491

I moved it to the wrong component, moving to Form Submission

Comment 4

[Boris Zbarsky [:bzbarsky]]

pavlov, is this yours?

Comment 5

[Darin Fisher]

cc'ing vinay... in case he has time to look into this.

Comment 6

[Vinay Badami]

Attachment: linux http req/response trace

Attachement shows that the behviour of the client is ok. There are no extra GET
requests being generated. 
This was on Linux.

Comment 7

[Vinay Badami]

Attachment: http request/response race on w2K

Shows that the client is behaving just fine on windows and there are no
extraneous GETs.

Comment 8

[Vinay Badami]

This should be marked as WFM/Invalid.
Please repopen only if u have a valid http request/response trace proving to the
contrary.
There are GET requests for the faviicon stuff that are getting redirected and
may result in happening after the POST request. But this is for the faviicon
image and not for same image that was returned from the POST request.

Comment 9

[Olav Vitters]

Attachment: Linux http req/response trace, Cache=Every time I view the page

Created a new profile and it seemed to work. I compared the settings between
the profiles and noticed that the problem only occurs if
Edit->Preferences->Advanced->Cache->Compare the page... is set to Every time I
view the page.

Attaching http trace.

Comment 10

[Vinay Badami]

yup - it does. Will look into this.

Comment 11

[Vinay Badami]

This is happenning in imgLoader::LoadImage as a result of the loadflags being
set to nsIRequest::VALIDATE_ALWAYS. 
It does not seem to take into account the fact that this could have been a POST
request with the content being the actual image. 
It goes out and makes a new request. If i force the value of flags to 0 in the
debugger, it ends up creating a CreateNewProxyForRequest and works ok loading
the POST image as opposed to the GET image.

Looking for suggestions on what the correct fix to this problem is.

Comment 12

[Alexandru Savulov]

Vinay:

if this is not form submission, can oyu set the correct component please?
thx!

BTW: looks like the testcase works with build#011403 

Comment 13

[John Keiser (jkeiser)]

Sounds like imglib to me.

Comment 14

[Jim Dunn]

The current URL doesn't load and instead brings up for me
http://www.widexs.nl/404.html.  If I think type in
http://www.widexs.nl/test/119132, I am asked for a username/password.

NOTE: I am hoping this might be fixed by bug 121084 patch, and I
want to check, so need working url/testcase

Comment 15

[Jim Dunn]

Attachment: zipped up tar test

This contains index.html, test.php, post.png & get.png
requires PHP running on server

Comment 16

[Jim Dunn]

Olav Vitters sent me the simple php testcase which showed this problem
when I set it up on my internal network.  I could recreate this problem
using 1.1 but I couldn't recreate it with 1.2.1, 1.3 or with the
current trunk.

marking fixed