Re: fragment stripping before URI dereferencing

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        cowan@ccil.org
'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

Received on Friday, 7 November 2014 01:15:35 UTC