Re: fragment stripping before URI dereferencing

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
>
>
>