Re: Comments on Byte range draft
Simon Spero (ses@tipper.oit.unc.edu)
Mon, 13 Nov 1995 16:07:58 -0800 (PST)
Just a few points:
If the byte range is carried in the URL, and is generated by the client,
then the client needs to know whether or not the server suports byte
ranges before generating the request- otherwise the request will be
rejected. If the information is stored in a header, then servers that
don't understand the header will just send the entire object.
Also, a general subdocument addressing facility must necessarily be more
complicated than a simple range, as it must be able to cope with
discontiguous areas. This sort of ability isn't need for restarting HTTP
requests, but is essential for caching proxies that are using lossy media
specific transfer protocols, where the initial fetch may be performed in
real-time, with losses, but which needs to be completed in non-real-time
before being used to serve other requests (see some of the RODEO work for
why lossy transports will become important).
All that's needed at the moment for this limited sub-problem is a quick
hack; since sticking stuff on the end of URLS takes more work than
sticking in an extra header in the request, and another in the response,
I'd go for the later approach. Add nocache to make sure that proxies
which don't understand byte-ranges don't cache it, and add another pragma
to reenable caching for proxies which do understand byte-ranges.
Request-
X-Byte-Range: [start]-[finish]
Response-
Pragma: no-cache, cache-if-you-understand-byte-range
X-Byte-Range: [start]-[finish]
(defun modexpt (x y n) "computes (x^y) mod n"
(cond ((= y 0) 1) ((= y 1) (mod x n))
((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
(t (mod (* x (modexpt x (1- y) n)) n))))