fragment stripping before URI dereferencing

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