Re: HTTP Partial Download Query

Dear Scott and Patrick,

Firstly Many thanks for your quick and precise inputs on this query.
But still I have following doubts.

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.
In such case how one can track if the download is complete or not?
How to track that the request is coming from same authenticated user?
I know that I can extract HTTP header information in FILTERS(in IIS terminology) or 
MODULES(in Apache terminolgy) but any other mechanism will be highly appreciated.

2)If you refer to section 19.2 of RFC 2616(http://rfc-2616.rfclist.com/rfc-2616-165.htm),
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.). 
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?


Please clear me if I am wrong in my understanding.

Thanks once again for your valuable time.

With Regards,
Yog




--------------------------------------------------------------------------------
Previous Communication related to HTTP PARTIAL DOWNLOAD
--------------------------------------------------------------------------------
> I was browsing through RFC 2616 for HTTP1.1
> One of the smart feature it mensioned was of PARTIAL DOWNLOAD.
> Means browser can specify a range of bytes (e.g 100-200 bytes of img123.gif)
> in the HTTP header and webserver will send only those bytes.
> 
> I have following query about PARTIAL DOWNLOAD
> 
> If the browser is capable of accepting say 100KB at a time (This 
> is most likely scenario in case of browsers on Mobile phones)
> then is it browser's responsibility to make request for every 100KB 
> of that object(which is to be downloaded) and the webserver will send requested 
> bytes? 
> OR
> Is it the server who will send the requested Object in chunk of 100KB
> with seperator and as Multipart response?

your first scenario is much closer.. the server will send only a
subset of the document.. if the client wants other subsets it must
make multiple requests. Also note that the server is allowed to just
send you the whole document even if you only ask for part of it.

imho, your issue appears to be one of flow control, which isn't really
what the range mechanism was meant for. (but then I'm not one to talk,
I've done an experiment to try and interleave different documents from
the same web page across the same persistent tcp stream using range).You should
really use your transport protocol to accomplish what you're
after. (e.g. in TCP advertise a 0 rwin and you won't get any more data
until you've consumed the last chunk.)

-Patrick
--------------------------------------------------------------------------
The client (browser) may request a specified range of the object; if
it wants another range, it must make another request.  The request is
made using the Range request header (see section 14.35 of RFC 2616).

Note however, that since a server MAY ignore a Range request header
and return the entire resource, a client that has a limited capacity
cannot always rely on getting a subrange response.  The Content-Range
header is included in the response if it is a subrange.

There is a mechanism (the 'Accept-Ranges' response header) designed to
allow the server to declare whether or not it will support range
requests for a resource - I don't know how widely it is implemented.
If it is implemented by the server, then an OPTIONS or HEAD request to
the URL of interest would return an Accept-Ranges header, without
having to deal with the entire object.

  Scott Lawrence
---------------------------------------------------------------------------

Received on Monday, 9 December 2002 00:31:23 UTC