[whatwg] Inconsistent behavior for empty-string URLs

I'd agree with that, I've yet been able to find an example of someone intentionally including an empty-string URL in one of these tags. 

-Nicholas
 
______________________________________________
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Monday, December 07, 2009 9:53 PM
To: Nicholas Zakas
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Mon, Dec 7, 2009 at 10:51 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Hi,
>
>
>
> In a recent investigation into capacity issues, I found that there are
> several instances where the browser will make a second to the page based on
> resolving empty-string URLs in the several tags. I tested four instances:
> <img src="">, <link href="">, <script src="">, and <iframe src="">. Across
> major browsers today, the behavior is vastly different:
>
>
>
> * Internet Explorer 8
>
> ? - Make a request for: <img src="">
>
> ? - Does not make a request for: <link href="">, <script src="">, <iframe
> src="">
>
> * Firefox 3
>
> ? - Make a request for: <img src="">, <link href="">, <script src="">
>
> ? - Does not make a request for: < <iframe src="">.
>
> * Firefox 3.5
>
> ? - Make a request for: <link href="">, <script src="">
>
> ? - Does not make a request for: <img src="">, ?<iframe src="">
>
> * Safari 4
>
> ? - Make a request for:<img src="">, ?<link href="">, <script src="">
>
> ? - Does not make a request for: <iframe src="">
>
> * Chrome 3 (same as Safari)
>
> ? - Make a request for:<img src="">, ?<link href="">, <script src="">
>
> ? - Does not make a request for: <iframe src="">
>
> * Opera 10
>
> ? - Make a request for: (none)
>
> ? - Does not make a request for: <img src="">, ?<link href="">, <script
> src="">, <iframe src="">
>
>
>
> Presently, HTML5 does provide guidance on the correct behavior for <img
> src=""> in section 4.8.2, indicating that Firefox 3.5's and Opera 10's
> behavior in this regard is correct:
>
>
>
> "If the base URI of the element is the same as the document's address, then
> the src attribute's value must not be the empty string."
>
>
>
> This seems like it should also apply to the other elements that download
> resources automatically. All browsers seem to be in agreement over the
> behavior of <iframe src=""> despite a lack of guidance in any HTML spec, and
> I'd assume that they will soon all be in agreement over <img src="">, per
> the HTML5 spec. It would be nice to formalize this behavior so that we can
> get all browsers to act in consistently in these confusing cases.
>
>
>
> My opinion is that Opera is the only browser currently doing this in a
> reasonable manner, in that it makes a lot of sense to me that an
> empty-string URL for an element that automatically downloads a resource
> should be considered invalid and ignored. My hypothesis is that these
> patterns are most frequently indications of errors rather than an
> intentional use of this little-known behavior, and as a result, sending
> another request is an unexpected and unwelcome result. For high-volume web
> sites, a single mistaken inclusion of one of these patterns immediately
> doubles page views, which can introduce capacity issues (which I've needed
> to investigate at least twice in the past three years).
>
>
>
> I'm interested in what others' opinions on this may be, as this seems like
> an important area in which to gain consistency.

Given that the concern is sites that accidentally leave a attribute
empty, wouldn't you want to prevent a request from going out even if
the base-uri is set? I.e. wouldn't you want to prevent a request from
going out for the current document:

foo.html:
<head><base src="bar.html">
<body><img src="">

It seems to me equally unlikely that someone would do that
intentionally expecting a request to be sent to "bar.html"?

/ Jonas

Received on Tuesday, 8 December 2009 09:36:49 UTC