Re: HTTP Partial Download Query

On Mon, 9 Dec 2002, Yogesh Bang wrote:

> 1) With your replies it seems that its the responsibility of the
> BROWSER to make the MULTIPLE GET request to get a LARGE OBJECT(lets
> say MOBILE RING TONES)  by using the RANGE header of HTTP request
> and the server merely send those requested BYTES.

Allow me to outline client-side and server-side options to clarify the
picture:

	Client option 1: send a simple GET request for the entire
	object and rely on transport mechanism (e.g., TCP buffer
	sizes) to limit sizes of incoming response chunks. This
	is probably "The Right Way" to do it as previous replies on
	this thread indicated.

	Client option 2: send a sequence of Range GET requests,
	each for a single subrange of the response small enough to
	satisfy your buffering requirements. This option relies on the
	server (and all HTTP intermediaries on the path!) supporting
	Range requests and not sending a complete response regardless
	of the Range header. Thus, using this option does not really
	make any practical sense unless you control the server and
	all HTTP intermediaries on the path.

	Client option 3: send a single Range GET request with several
	subranges, each small enough to satisfy your buffering
	requirements. Rely on transport mechanism to limit sizes of
	incoming response chunks. Note that the client may or may not
	receive multipart/byteranges response, depending on whether
	the server can handle Range requests and whether the server
	will merge overlapping subranges and realize that they are
	equivalent to the whole object. Thus, using this option does
	not really make any practical sense unless you control the
	server and all HTTP intermediaries on the path.


	Server option 1: ignore Range header and send complete
	response.

	Server option 2: honor Range request and send just the
	requested range(s). Use multipart/byteranges if there
	is more than one range requested.

	Server option 3: honor Range request and merge requested
	ranges if possible. If the result is an entire object,
	send a normal response as if the Range header was ignored.

If you look at all the options above, you will realize that you cannot
rely on Range requests to limit transfer chunks _unless_ you control
the server and all intermediaries.

> In such case how one can track if the download is complete or not?

The client would know if it received the whole object because a
partial response contains the content length of the complete response.
The server cannot reliably aggregate individual request sizes for
reporting unless server authentication is used and request threads for
the same URL do not overlap. If server authentication is used, one can
aggregate sizes of individual ranged responses on a per-user per-URL
basis.

> How to track that the request is coming from same authenticated
> user?

Each request should have authentication information attached, of
course.

> 2)If you refer to section 19.2 of RFC 2616, it depicts a scenario of
> HTTP Partial download. In this scenario the requested object is send
> as MULTIPART/BYTERANGES type seperated by a seperator. It seems it
> is a SINGLE response send as MULTIPART with each part cut into small
> chunks (which can be accepted by browser.).

Yes, in general, you get a single response for a single request
(regardless of Range header presence or value). If you want multiple
responses, you have to send multiple requests (probably with different
Range headers).

> If this is the way HTTP PARTIAL DOWNLOAD works then to implement
> this functionality what care a Web-Programmer needs to take ? Does
> he need to write a seperate DOWNLOAD program which will cut the
> requested object into chunks ,put the seperators and send it to
> browser as single response?

That would be one option. It is difficult to give a specific design
advice without knowing a lot more about your environment. Please note
that most decent HTTP servers (e.g., Apache) support Range requests
for static objects. Please also note that an HTTP intermediary can
change a Range request into a simple GET.

Overall, just based on the information you gave us so far, it seems
that using Ranges is the wrong mechanism to limit response chunks in a
general Web environment. I would expect the transport mechanism (e.g.
TCP) in the browser to handle browser buffering limitations.

Thanks,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Monday, 9 December 2002 12:15:13 UTC