fragment stripping before URI dereferencing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

fragment stripping before URI dereferencing

Rushforth, Peter-2
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).

 

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

 

Reply | Threaded
Open this post in threaded view
|

Re: fragment stripping before URI dereferencing

Silvia Pfeiffer

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" <[hidden email]> 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).

 

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

 

Reply | Threaded
Open this post in threaded view
|

Re: fragment stripping before URI dereferencing

John Cowan-3
In reply to this post by Rushforth, Peter-2
Rushforth, Peter scripsit:

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

The media type specifies the meaning of a fragment identifier, but it
is the responsibility of client software to take action in accordance
with that meaning.  For example, in text/plain documents the fragment
identifier "#line=10,20" specifies lines 10 through 20 of the document
per RFC 5147.  But whereas a browser might simply scroll to place line
10 at the top and perhaps highlight the range, a downloader might discard
all but lines 10 through 20 and save them to the download area.

> 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

That ship sailed decades ago.  HTTP servers don't expect to see fragment
IDs in requests and will malfunction if they get them, and non-HTTP
servers don't have any protocol for accepting them at all.  The exchange
between clients and servers is in terms of entity-bodies representing
whole resources.  Nothing else is practical at this stage.

(HTTP 1.1 clients and servers can pass around pieces of entity bodies
using the Range and Content-Range headers, but that's low-level and
meant for fragmentation, not for semantic fragments.)

--
John Cowan          http://www.ccil.org/~cowan        [hidden email]
'My young friend, if you do not now, immediately and instantly, pull
as hard as ever you can, it is my opinion that your acquaintance in the
large-pattern leather ulster' (and by this he meant the Crocodile) 'will
jerk you into yonder limpid stream before you can say Jack Robinson.'
        --the Bi-Coloured-Python-Rock-Snake

Reply | Threaded
Open this post in threaded view
|

Re: fragment stripping before URI dereferencing

Gannon Dick

--------------------------------------------
On Thu, 11/6/14, John Cowan <[hidden email]> wrote:


 Rushforth, Peter
 scripsit:
 

 > 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
 
 That ship sailed decades ago.  HTTP servers don't expect to see fragment IDs in
 requests and will malfunction if they get them, and non-HTTP servers don't have any protocol
 for accepting them at all.  The exchange between clients and servers is in terms of
 entity-bodies representing whole resources.  Nothing else is practical at this stage.
 
 (HTTP 1.1 clients and servers can pass around pieces of entity bodies using the Range and Content-Range headers, but that's low-level and meant for fragmentation, not for semantic fragments.)
 
-----------------------------------------------------------------

Yup, ship's gone.

If the [Registry or Flag of Convenience or Group Identity] are important, as they are for long term ontology  management, then you can use Strategy Markup Language (StratML) or Asset Description Metadata Schema (ADMS).

--Gannon

P.S. Please don't mention to The Surveillance Society that group identity is a probability not a tattoo.
It makes her grumpy.  Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: fragment stripping before URI dereferencing

Graham Klyne-2
In reply to this post by John Cowan-3

On 07/11/2014 01:15, John Cowan wrote:

>> 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
> That ship sailed decades ago.  HTTP servers don't expect to see fragment
> IDs in requests and will malfunction if they get them, and non-HTTP
> servers don't have any protocol for accepting them at all.  The exchange
> between clients and servers is in terms of entity-bodies representing
> whole resources.  Nothing else is practical at this stage.
>
> (HTTP 1.1 clients and servers can pass around pieces of entity bodies
> using the Range and Content-Range headers, but that's low-level and
> meant for fragmentation, not for semantic fragments.)

Agreed, but...

There's still an option to use HTTP Link: headers to provide additional URI
information, such as fragments.  Whether that's a good idea is debatable, and
almost certainly  use-case dependent.

#g
--