RE: Re: Partial file shating!!

  To know the partial file ranges, I have used HEAD instead of GET. The interesting thing is I have neither seen 206 responses nor "X-Available-Ranges” for HEAD request!!
 
 Is that "Partial File Sharing Protocol Version (PFSP)" specs still hold true? 
 
 Regards,
 
 
   
   
  


Philippe Verdy <[email protected]> wrote:                                  From [email protected]:
 > Quoting rakesh <[email protected]> from ml.gnutella.dev-forum:
 > > Thanks Raphael
 > > For Gnutella as per "Partial File Sharing Protocol Version (PFSP)
 > > 1.0", the client requests the range it wants using the Range header.
 > >
 > > Range: bytes=0- means the client wants any ranges the server can
 > > provide.
 > 
 > The PFSP specs are in error.  The above simply means you're requesting the
 > whole file. So this Range: header is ignored and that's why you don't get
 > a 206.
 > 
 > > The issue is - I want to know all the parts of a file that peer share.
 > > For that I request with "Range: bytes=0-", but none of the peer respond
 > > with 206 and "X-Available-Ranges: " headers.
 > >
 > > They respond with 206 only when I specify random range in the "Range:"
 > > headers.
 > > That requires a range in Range header which is not known at the time of
 > > request.
 > >
 > > How we can know the all the shared parts of files?
 > 
 > You assume the file is complete and request what you need.  Then if the
 > range is not available, you'll get a 416 and the X-Available-Range: header
 > will tell you which parts can be requested.  Good servents will keep the
 > connection open on a 416, so you may retry one of the advertised ranges,
 > if any suits you.
 
 The "Range:" header is completely described in the http specification. Read
 RFC 2616 for the exact meaning and acceptable values.
 
 Whatever the PFSP specs says is just indicative here, as this header is sent
 as part of a regular HTTP request. In case of conflicts, the standard HTTP
 specs of the RFC are ALWAYS right when it says "MUST" or SHALL"!
 
 Nothing in the HTTP specs indicates that the reply may ort may not contain a
 "X-Available-Ranges:" extra header (which is not forbidden). However the
 HTTP spec does not guarantee that such header will be transmitted through
 proxies and it does not describe how this extra header would be cached.
 
 But here we know that we won't use caching HTTP proxies, and the PFSP spec
 may indicate that an "X-Available-Ranges:" header "should" be returned. (In
 fact, the standard HTTP protocol does not expect this header to be returned,
 as it expects that every HTTP source either has a complete version of the
 requested resource or no part of it: there's no space in HTTP for partial
 sources, not even in caching proxies).
 
 Raphael is right when it says that a request with Range: bytes 0- means
 requesting a whole file. It is normal to return a 206 error when the whole
 file is not available, but NOTHING forbids returning the 206 error with the
 list of available ranges, so that the requester can still request again only
 those ranges...
 
 If you want to get only the list of ranges without downloading the whole
 file, use the same request but with the "HEAD" verb instead of the "GET"
 verb (the answer MUST use the same status and headers, except that the
 client indicates that it does not want the data body immediately: you'll get
 a 206 error too if only some ranges are available, or 404 NOT FOUND error if
 nothing is available, or 200 OK if the whole file is available or a redirect
 status if some metadata is known but located somewhere else). So just send:
 
  HEAD /path/resource-name HTTP/1.1
  Host: ip1.2.3.4
 
 You don't need to send "Range: bytes 0-" which is superfluous.
 
 Note that HTTP/1.1 still maintains the connection by default so the reply
 will not close it after completing the HEAD request, unless the reply uses
 the 404 NOT FOUND error, or any status above 400 (in which case, the server
 will add the header "Connection: close" in its reply to indicate to the
 client that it cannot perform another query and that it should close the
 session to the server). If the return status is lower than 400, the server
 should still accept and honor another request from the client, and should
 NOT return "Connection: close" (if the server replies with HTTP/1.1).
 
 If the server replies with HTTP/1.0, it may either close the connection
 itself (not recommended, it should better wait during at least 5 to 15
 seconds, to give sometime to the client) or indicate to the client that it
 maintains the connection for accepting further requests (by returning
 "Connection: keep-alive" only for requests that do not complete with status
 400 or above).
 
 If a client receives a HTTP/1.0 reply from a server with a status at 400 or
 above, it should close the connection as soon as possible after parsing the
 reply headers, to save resources on the server.
 
 The client should do the same thing if it receives a HTTP/1.1 reply from a
 server, but only if the "Connection: close" header is present in that reply
 (the client may continue to perform a request to the server EVEN if the
 HTTP/1.1 status was 400 or more: HTTP/1.1 is better here because the server
 decides what to do and what it can accept, independently of the nature of
 the reply)
 
 
     
                       

       
---------------------------------
Luggage? GPS? Comic books? 
Check out fitting  gifts for grads at Yahoo! Search.

[Non-text portions of this message have been removed]