Closed Bug 286979 Opened 19 years ago Closed 19 years ago

Empty src attribute of image tags leads to rerequest of page

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 225554

People

(Reporter: the-pulse, Assigned: darin.moz)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0

When sending a POST request and there is an image tag (or input tag with
type="image") with an empty src attribute in the response, the page is
rerequested via GET. Though it's not the best server behavior not to consider
the method, this can lead to multiple execution of the same action, once with,
once without data. Links to stylesheet or javascript files might be affected to,
I have not checked.

For detailed information refer to RFC 2396, section 4.2 "Same document references".

http://www.ietf.org/rfc/rfc2396.txt

Even though it's a "should"-criteria, the behavior does not make sense, since
one document is an html page and the second one is an image. Since http is
stateless, the server can not detect which kind of document should be delivered.

Reproducible: Always

Steps to Reproduce:
1. This page is sufficient:

<html><head />
<body>
<form method="POST">
  <input type="image" src="">
<form>
</body>
</html>

2. Put the document onto your webserver
3. Request the document
4. Press the button.

Maybe you have to switch off your browser cache.
Actual Results:  
After submitting, the URL of the document appears in the server log 3 times. One
time for the first request, and twice for the second one.

Expected Results:  
The image should have been displayed as broken without another request being sent.

Tested version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0
see also 5.2.2).

why would this be a bug? Clearly, the server can distinguish. It can use the
request method or the Accept: header. Or it can send a cookie with the POST
request and check that.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Cookies are not the way to solve it, because they simply might be
switched off. I don't like to punish people who care about privacy.
Agreed, the Accept-header can even be useful to provide the same content
in different formats, and an html page might be used as a wrapper for
graphical content.

But though it's an acceptable behaviour to load the image, it is not the
best:
1. Intutively I would not expect a browser to try to load an HTML-page
as an image.
2. The RFC recommends a different behaviour (not loading the image).
3. The browser causes needless network traffic since it loads an image
that is predictably invalid. This is the case because 2. implies that
web applications must not implement invocations of images by using empty
urls as image sources.
4. Probably, the page could even be displayed faster if the request
would not be sent.

I'm saying this only to answer you question. It just took me a little
time to find out what's up, and I thought it would be nice to share the
information with you. Using VNC while debugging I found out that IE is a
little smarter in this single point ;)

Fixing it might be complicated and might not be worth the effort.
Anyway, most users won't care and it might be better to keep the old
behavior than to possibly introduce new, more serious bugs.

Thanks and regards

Sven
(In reply to comment #2)
> But though it's an acceptable behaviour to load the image, it is not the
> best:
> 1. Intutively I would not expect a browser to try to load an HTML-page
> as an image.

How can the browser know that the request will lead to an HTML page?

> 2. The RFC recommends a different behaviour (not loading the image).

I can't find such a statement. Can you quote the relevant part?

> 3. The browser causes needless network traffic since it loads an image
> that is predictably invalid.

No, that's not predictable. I mentioned a few cases how the server can
differentiate between the form result and the <img>.

> This is the case because 2. implies that
> web applications must not implement invocations of images by using empty
> urls as image sources.

I agree that this is not usual for <img>. But Mozilla won't special-case URL
resolution for <img> vs all other URI references (<a>, <iframe>, etc.)

> 4. Probably, the page could even be displayed faster if the request
> would not be sent.

The question is, why does the page even contain an <img> with an empty href?

> I'm saying this only to answer you question. It just took me a little
> time to find out what's up, and I thought it would be nice to share the
> information with you. Using VNC while debugging I found out that IE is a
> little smarter in this single point ;)

I would claim it violates the rfc ;)

We had previous bug reports on this issue... they are also marked invalid. ;)
(f.ex. bug 263239 comment 4)

> Fixing it might be complicated and might not be worth the effort.

Well, making empty hrefs fail would be a two-line change in nsIOService.cpp. (if
(aSpec.IsEmpty()) return NS_ERROR_MALFORMED_URI;), but there are places on the
web where such empty hrefs are indeed used.

(In reply to comment #3)
> > 1. Intutively I would not expect a browser to try to load an HTML-page
> > as an image.
> 
> How can the browser know that the request will lead to an HTML page?

It has requested an html page using the same url.

> > 2. The RFC recommends a different behaviour (not loading the image).
> I can't find such a statement. Can you quote the relevant part?

"Traversal of such a reference should not result in an additional retrieval
action." 

> > 3. The browser causes needless network traffic since it loads an image
> > that is predictably invalid.
> No, that's not predictable. I mentioned a few cases how the server can
> differentiate between the form result and the <img>.

If a web application relies on the browser fetching the image, it will break
with browsers that follow the recommendation and do not (eg. IE).

> > This is the case because 2. implies that
> > web applications must not implement invocations of images by using empty
> > urls as image sources.
> 
> I agree that this is not usual for <img>. But Mozilla won't special-case URL
> resolution for <img> vs all other URI references (<a>, <iframe>, etc.)

That is the part that makes it complicated to fix.

> The question is, why does the page even contain an <img> with an empty href?

By error ;) I was develloping a web page and some images were still missing. I
used it as a placeholder.

> > Using VNC while debugging I found out that IE is a
> > little smarter in this single point ;)
> 
> I would claim it violates the rfc ;)

Yes, often and willingly.

> Well, making empty hrefs fail would be a two-line change in nsIOService.cpp. (if
> (aSpec.IsEmpty()) return NS_ERROR_MALFORMED_URI;), but there are places on the
> web where such empty hrefs are indeed used.

Yes, they are in use as reference to the next page, but not to include an image,
a style sheet or javascript code. Empty hrefs should not fail in these cases,
they should refer to the data that is already in memory.

Sven
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Duping to invalid bug

*** This bug has been marked as a duplicate of 225554 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
> "Traversal of such a reference should not result in an additional retrieval
> action." 

That whole section is an attempt to weasel-talk about fundamental brain-damage
in the way that URI references (thing starting with '#') and base URI changes
interact....  More to the point, in this case, there is no "traversal" -- there
is a simple request for a retrieval action.

Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.