- From: Simon Spero <ses@tipper.oit.unc.edu>
- Date: Mon, 13 Nov 1995 16:07:58 -0800 (PST)
- To: Lou Montulli <montulli@mozilla.com>
- Cc: Larry Masinter <masinter@parc.xerox.com>, ietf-lists@proper.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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))))
Received on Monday, 13 November 1995 16:11:28 UTC