W3C home > Mailing lists > Public > uri@w3.org > November 2014

Re: fragment stripping before URI dereferencing

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 7 Nov 2014 06:48:59 +1100
Message-ID: <CAHp8n2kNCfNKFtmuotFagi8DzHibv+zbaPhfrZ_n8iM9JX2mFg@mail.gmail.com>
To: "Rushforth, Peter" <Peter.Rushforth@nrcan-rncan.gc.ca>
Cc: uri@w3.org
We've had to deal with these issues in the media fragment uri working
group. You might want to check out the result.
http://www.w3.org/TR/media-frags/

This version is more complete atlas not a recommendation:
http://www.w3.org/TR/2011/CR-media-frags-20111201/

Best Regards,
Silvia.
On 7 Nov 2014 01:46, "Rushforth, Peter" <Peter.Rushforth@nrcan-rncan.gc.ca>
wrote:

>  Hi,
>
>
>
> According to HTTP [1],
>
>     The target URI excludes the reference's fragment component, if any,
>
>    since fragment identifiers are reserved for client-side processing
>
>    ([RFC3986], Section 3.5 <https://tools.ietf.org/html/rfc3986#section-3.5>).
>
>
>
> OK, so URI [2] is responsible for how fragments are processed.
>
>
>
> According to [2], the media type is granted broad authority over how
> fragment identifiers are interpreted, and
>
> no URI scheme can take that away.  Great! The media type is now in
> charge.
>
>
>
> But then, the media type’s authority is immediately stripped away:
>
>
>
>    the fragment identifier is not used in the scheme-specific
>
>    processing of a URI; instead, the fragment identifier is separated
>
>    from the rest of the URI prior to a dereference, and thus the
>
>    identifying information within the fragment itself is dereferenced
>
>    solely by the user agent, regardless of the URI scheme.
>
>
>
> The following is the justification for the loss of information:
>
>
>
>    it also serves to prevent information
>
>    providers from denying reference authors the right to refer to
>
>    information within a resource selectively.
>
>
>
> Can someone explain that to me, please?  I think the ‘secondary resource’
> identified by fragment identifiers
>
> could be extremely useful not only on the client but also to the origin
> server (for example, a hint as to where to start
>
> serving out an extremely large resource), so the injunction on their
> transmission seems to push media type authors
>
> towards adding protocol extensions to compensate e.g. a ‘Fragment: ‘ HTTP
> extension header
>
> or something like that.
>
>
>
> Thanks for your thoughts on the topic.
>
>
>
> [1] https://tools.ietf.org/html/rfc7230#section-5.1
>
> [2] https://tools.ietf.org/html/rfc3986#section-3.5
>
>
>
>
>
> Peter Rushforth
>
>
>
Received on Thursday, 6 November 2014 19:49:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:17 UTC