Re: Byte ranges -- formal spec proposal

Marc VanHeyningen (marcvh@spry.com)
Thu, 18 May 1995 15:02:46 +0500


Brian Behlendorf sed:
> On Wed, 17 May 1995, Larry Masinter wrote:
> > The proposal is to add byte ranges to URLs (in general, it seems). I
> > don't think it belongs there; at best, byte ranges make sense as an
> > addon to the HTTP protocol.
>
> Then how does one build a URL to point to minutes 6 through 8 of a 1-hour
> 60-megabyte DJ set? Or to message 2064 (byte range 2254322-2257934) in a
> 4 megabyte mailbox archive? Sure, if I'm using an HTTP-aware mailbox
> reader or audio viewer that's a possibility... but then I can only launch
> a range request from that type of viewer. Ick.

I'd also like to see something more general. (I'd also like to see something
integrated with, rather than orthogonal to, existing fragment references
but that's just me.)

> http://host/path/to/object?object_arguments;request_headers
>
> object_arguments: a url-encoded list of name-value pairs
> i.e. name=brian&age=22
>
> request_headers: a url-encoded list of request headers, which only
> make sense in the context of the protocol used (in this case HTTP)
> This generality is so that URL's aren't hindered by HTTP-only
> specifications.

This also has interesting potential to allow hacks like the extra anchor
stuff like DN and CRYPTOPTS in SHTTP to be folded into the URLs.

> I can already sense some problems. Here's an interesting URL:
>
> http://whitehouse.gov:25/;MAIL+FROM=madmad@bomber.org&RCPT+TOpresident&DATA\nFrontLawn,2pm,May16th\n.\n
>
> Though I suppose some catches could be put in place for this situation,
> can we protect against that for every protocol? At what point does a
> sufficiently obfuscated (to the human eye) extended URL become a malicious
> virus-ish mechanism for mayhem?

You can do that today with Gopher URLs; this vulnerability has been known
about for years, popular browsers are susecptible to it, and nobody seems to
be complaining, so obviously it's not a real problem. :-) * 0.5

- Marc

Marc VanHeyningen marcvh@spry.com
Disclaimer:
If this were an official announcement from Spry-CompuServe Internet Division,
it would have begun with the phrase "FOR IMMEDIATE RELEASE."