> There are number of Web applications that would benefit from being
> able to request the server to give a byte range of a document.
and I asked
> Name two.
and Ari replied:
> 1. A custom application on the client side that works on some
> page-oriented document format, such as FrameMaker docs or PDF.
but I still ask:
Please give a single, specific and realistic example. If you think a
framemaker document can be retrieved a byte range at a time, what is
the initial byte range? How do you know?
Can PDF documents be retrieved partially? A priori? How many bytes
would you know to ask for in the first place? Is 'the first part of a
PDF file' still 'application/pdf'?
> 2. Just regular Web clients where image or document transfer is
> interrupted before the entire image/document is received, and then
> later restarted. So instead of starting all over again you could only
> transfer the remaining part of it.
This is http specific, isn't it? Surely a FTP server won't support
this. So, does this belong in the URL at all?
I think these are both scenarios that might benefit from a GET-PARTIAL
or some kind of modification to GET in HTTP, but I don't see either of
these scenarios being justification for a new feature in URLs.
The discussion seems to have confounded fragment identifiers (where
the URL points to a part of another object, but the request is 'get
the whole object, but direct attention to this part') with some kind
of 'partial object retrieval' (retrieve this other resource which is a
particular subpiece of the original one.)
Fragment identifiers occur after #, but the ';' separator is reserved
in a variety of URL schemes. Unless you intend this to only work with
HTTP? That isn't what the proposal said.