[Yum-devel] request for advice

Scott Robinson scott at quadhome.com
Thu Aug 18 21:28:29 UTC 2005

It seems to me that a HEAD request is the exact thing to solve this
problem. For example:

scott at geneva:~/x$ telnet sentinel-a.trustsentinel.com 80
Connected to sa8169024.temp.wsu.edu.
Escape character is '^]'.
HEAD /~scott/repo.asc HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 18 Aug 2005 21:26:14 GMT
Server: Apache/2.0.52 (Fedora)
Last-Modified: Thu, 18 Aug 2005 01:22:21 GMT
ETag: "244293-41a-b748d40"
Accept-Ranges: bytes
Content-Length: 1050
Connection: close
Content-Type: text/plain; charset=UTF-8

I now know the total length and last modified date for the file. I can
then determine my proper response from that.

If a HEAD response doesn't return the information, just assume the
entire file needs to re-downloaded?


On Thu, Aug 18, 2005 at 11:51:23AM -0700, Michael Stenner wrote:
> OK, this reget thing is really annoying me.  Here's the deal:
>   If you do http reget on a complete file, it uses a byterange that
>   starts after the last byte and says "the rest".  This (depending on
>   which section you read) is an illegal range specifier and results in
>   a 416.
>   The trouble is that there's no good way to know that the file is
>   complete before you try.
> I can think of a few ways to tackle this:
>   1) catch the 416, but interpret it as success (perhaps for reget
>      only) 
>   2) perform some sort of query first to determine the length - ick
>   3) use If-Range, which will cause it (I think) to just send the
>      whole file if there's a range error (which in this case sometimes
>      happens when we ALREADY HAVE the whole file)
> Any other ideas?  This would be so much nicer if it just allowed for a
> zero-length request.
> 					-Michael
> -- 
>   Michael D. Stenner                            mstenner at ece.arizona.edu
>   ECE Department, the University of Arizona                 520-626-1619
>   1230 E. Speedway Blvd., Tucson, AZ 85721-0104                 ECE 524G
> _______________________________________________
> Yum-devel mailing list
> Yum-devel at linux.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

http://quadhome.com/            - Personal webpage
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20050818/b8bc91d2/attachment.pgp 

More information about the Yum-devel mailing list