Re: parsing URI (references) according to RFC 3986

On 2011-06-23 20:05, Boris Zbarsky wrote:
> On 6/23/11 1:23 PM, Julian Reschke wrote:
>> "When a same-document reference is dereferenced for a retrieval action,
>> the target of that reference is defined to be within the same entity
>> (representation, document, or message) as the reference; therefore, a
>> dereference should not result in a new retrieval action."
>>
>> Test case: <http://greenbytes.de/tech/tc/uris/imgsame.html>
>>
>> You are right, Firefox does something bizarre; it indeed sends a GET
>> request for http://greenbytes.de/tech/tc/uris/imgsame.html#foo (note
>> that fragment identifier in the request URI).
>
> Can't reproduce that part; I have no idea how you got that result (e.g.
> which exact tool you used to record what Firefox sends, nor which
> Firefox version you used). In my case, using Firefox 4, the image is
> just read from cache. But that's not the point.

Using Firefox 5; looking at the "Net" tab under "Options" -> "Web 
Developer" -> "Web Console"; I just checked my server log and it does 
seem to be a bug in the tool.

>> Now is the concern the fragment identifier (which seems to be a specific
>> problem of Firefox), or the fact that browsers do a refetch?
>
> Your testcase is not testing what really needs testing here.
>
> What needs testing is a document at
> <http://greenbytes.de/tech/tc/uris/imgsame.html> with a <base
> href="http://greenbytes.de/tech/tc/uris/imgother.html"> and an <img
> src="#foo">.
>
> Per section 4.4 as I read it, and per your comments just now, that
> should load http://greenbytes.de/tech/tc/uris/imgsame.html as an image.
> Does anyone do that?

?

4.4 defers to section 5.1 for the definition of the base URI, and makes 
it media type dependent how to find it. So the HTML spec needs to answer 
that question (also, related questions with respect to changing the base 
URI after the document was loaded)-

>> Or, leave it in (I'm pretty sure there's a good reason for it), but
>> state that there may be cases where the context may require refetching
>> the resource.
>
> See above; the refetching is not the issue.
>
>> (we do agree that the advice holds for <a> links inside HTML, right?)
>
> Do we?
>
> Consider the following HTML documents:
>
> main.html:
>
> <!DOCTYPE html>
> <iframe src="subframe1.html"></iframe>
> <iframe name="subframe2" src="subframe2.html"></iframe>
>
> subframe1.html:
>
> <!DOCTYPE html>
> <base href="subframe2.html">
> <a href="subframe2.html#foo" target="subframe2">Click me</a>
>
> subframe2.html:
>
> <!DOCTYPE html>
> <base href="something-else.html">
> <script>alert('loaded')</script>
> Will I scroll?
> <div style="height: 5000px"></div>
> <div id="foo">Can you see me now?</div>
>
> Now the user clicks that link in the first iframe? What happens? How is
> one supposed to even apply 4.4 here? Which URI is "the base URI"? Which
> entity is the reference "in"? How can the URI spec even define this?

It doesn't. HTML needs to define it.

> ...

Best regards, Julian

Received on Thursday, 23 June 2011 18:27:51 UTC