Prev: See and Enjoy Indian Girls Gallery.
Next: Mousewheel event does not support DOM0 in FF
From: Richard Cornford on 3 Jun 2010 03:50
Joe Nine wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Joe Nine wrote:
>>> Scott Sauyet wrote:
>>> Thanks Scott (and Thomas in his reply). I hadn't realized (and
>>> find it quite strange) that creating a tag with a blank src
>>> attribute would request the current HTML file for the JS. How
>>> unusual, [...]
>>
>> Only to the uninitiated, I am afraid. The value of the `src'
>> attribute of SCRIPT elements is specified to be of type
>> URI⁽¹⁾, that is, a URI or URI- reference as specified in RFC
>> 3986⁽²⁾ (which obsoletes RFC 2396, which updates RFC 1738,
>> which is therefore referred in the HTML 4.01 Specification⁽³⁾).
>>
>> An empty URI-reference is specified to be a same-document
>> URI-reference.⁽⁴⁾ You can find that, for example, with the
>> `action' attribute of FORM elements, too, primarily if the
> document is dynamically generated by a server-side application
>> (like PHP).⁽⁵⁾
>>
>> You're welcome :)
>snip>
> Wouldn't the same logic apply to an IMG tag with src="" that's
> being written using document.write? As far as can be observed,
> it doesn't seem to suffer from the same behavior and simply
> sits there waiting for someone to come along and set it's src
> attribute.

What evidence do you have that an IMG element in an HTML document with
an empty SRC URL does not 'load' that HTML document into itself?
Specifically, do you have any evidence that this IMG element behaves any
differently from a similar IMG element that has its SRC element
explicitly set to refer to an HTML document.

Historically IMG elements have been exploited for their ability to
request arbitrary resources from a server and 'sink' any non-image
results they happen to be sent. An IMG directed at an HTML source can be
expected to go through the HTTP process (which will involve a request to
the server is caching does not interfere) and download the servers
response, but as the result would not be interpretable as an image the
visible behaviour would be as if nothing has been downloaded.

Richard.

From: Thomas 'PointedEars' Lahn on 3 Jun 2010 04:52
Joe Nine wrote:

> Thomas 'PointedEars' Lahn wrote:
>> An empty URI-reference is specified to be a same-document
>> URI-reference.⁽⁴⁾ You can find that, for example, with the `action'
>> attribute of FORM elements, too, primarily if the document is dynamically
>> generated by a server-side application (like PHP).⁽⁵⁾
>
> Wouldn't the same logic apply to an IMG tag with src="" that's being
> written using document.write?

IMG _element_: Yes, it would.

> As far as can be observed, it doesn't seem to suffer from the same
> behavior and simply sits there waiting for someone to come along and
> set it's src attribute.

Do not rely on that; a user agent may prune pointless requests, but it does
not need to. Do not use empty URI-references anywhere unless you mean it.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Joe Nine on 3 Jun 2010 08:55
Richard Cornford wrote:
> Joe Nine wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Joe Nine wrote:
>>>> Scott Sauyet wrote:
>>>> Thanks Scott (and Thomas in his reply). I hadn't realized (and
>>>> find it quite strange) that creating a tag with a blank src
>>>> attribute would request the current HTML file for the JS. How
>>>> unusual, [...]
>>>
>>> Only to the uninitiated, I am afraid. The value of the `src'
>>> attribute of SCRIPT elements is specified to be of type
>>> URI⁽¹⁾, that is, a URI or URI- reference as specified in RFC
>>> 3986⁽²⁾ (which obsoletes RFC 2396, which updates RFC 1738,
>>> which is therefore referred in the HTML 4.01 Specification⁽³⁾).
>>>
>>> An empty URI-reference is specified to be a same-document
>>> URI-reference.⁽⁴⁾ You can find that, for example, with the
>>> `action' attribute of FORM elements, too, primarily if the
>> document is dynamically generated by a server-side application
>>> (like PHP).⁽⁵⁾
>>>
>>> You're welcome :)
>> snip>
>> Wouldn't the same logic apply to an IMG tag with src="" that's
>> being written using document.write? As far as can be observed,
>> it doesn't seem to suffer from the same behavior and simply
>> sits there waiting for someone to come along and set it's src
>> attribute.
>
> What evidence do you have that an IMG element in an HTML document with
> an empty SRC URL does not 'load' that HTML document into itself?
> Specifically, do you have any evidence that this IMG element behaves any
> differently from a similar IMG element that has its SRC element
> explicitly set to refer to an HTML document.


No evidence, only the lack of any observed misbehavior or warnings in
the error console.

> Historically IMG elements have been exploited for their ability to
> request arbitrary resources from a server and 'sink' any non-image
> results they happen to be sent. An IMG directed at an HTML source can be
> expected to go through the HTTP process (which will involve a request to
> the server is caching does not interfere) and download the servers
> response, but as the result would not be interpretable as an image the
> visible behaviour would be as if nothing has been downloaded.
>
> Richard.

Well that would explain the lack of warning. Personally, I'd issue a
warning in the console that a non-image failed to load into the IMG element.
From: Joe Nine on 3 Jun 2010 08:57
Thomas 'PointedEars' Lahn wrote:
> Joe Nine wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> An empty URI-reference is specified to be a same-document
>>> URI-reference.⁽⁴⁾ You can find that, for example, with the `action'
>>> attribute of FORM elements, too, primarily if the document is dynamically
>>> generated by a server-side application (like PHP).⁽⁵⁾
>> Wouldn't the same logic apply to an IMG tag with src="" that's being
>> written using document.write?
>
> IMG _element_: Yes, it would.
>
>> As far as can be observed, it doesn't seem to suffer from the same
>> behavior and simply sits there waiting for someone to come along and
>> set it's src attribute.
>
> Do not rely on that; a user agent may prune pointless requests, but it does
> not need to. Do not use empty URI-references anywhere unless you mean it.
>
> PointedEars

There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
From: Richard Cornford on 3 Jun 2010 09:31
On Jun 3, 1:55 pm, Joe Nine wrote:
> Richard Cornford wrote:
>> Joe Nine wrote:
<snip>
>>> Wouldn't the same logic apply to an IMG tag with src=""
>>> that's being written using document.write? As far as can be
>>> observed, it doesn't seem to suffer from the same behavior
>>> and simply sits there waiting for someone to come along and
>>> set it's src attribute.
>
>> What evidence do you have that an IMG element in an HTML
>> document with an empty SRC URL does not 'load' that HTML
>> document into itself? Specifically, do you have any evidence
>> that this IMG element behaves any differently from a similar
>> IMG element that has its SRC element explicitly set to refer
>> to an HTML document.
>
> No evidence, only the lack of any observed misbehavior or
> warnings in the error console.

What would be misbehaviour? An element that exists to display images
displaying nothing when presented with data that cannot (and should
not, because of its Content-Type header) be interpreted as an image is
quite reasonable behaviour.

>> Historically IMG elements have been exploited for their ability
>> to request arbitrary resources from a server and 'sink' any
>> non-image results they happen to be sent. An IMG directed
>> at an HTML source can be expected to go through the HTTP
>> process (which will involve a request to the server is
>> caching does not interfere) and download the servers
>> response, but as the result would not be interpretable as
>> an image the visible behaviour would be as if nothing has
>> been downloaded.
>
> Well that would explain the lack of warning. Personally, I'd
> issue a warning in the console that a non-image failed to
> load into the IMG element.

And get a warning every time an image failed to load for any other
reason?

Richard.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: See and Enjoy Indian Girls Gallery.
Next: Mousewheel event does not support DOM0 in FF