[squid-users] RFE - HTTP 1.1 RANGES

If I missed this, please let me know, but I was wondering why
HTTP 1.1 wasn't on the list on the roadmap? I don't know all
the details, but compression and RANGES are two that could
speed up web usage for the average user.

Ranges, it seems to me, could be kept in a binary-sized
linked-list of chunks corresponding to the content downloaded
'so far'. It might be that the content stored might never get
filled up before being re-used, but at least it would allow
the storage and potential reuse of a 'range' when rounded to the
nearest 'min-chunk-size' (~4K?, 8K? user config item). Could
even use seeks over blank areas rather than initializing it to
some value to encourage sparse file usage on file systems that
support such files.

Would it be that difficult to at minimum, view a byte ranged
file as a sequence of 4K files where squid starts downloading
them from the nearest 'pseudo file' to store it on disk. That
way users could benefit from byte ranges for update servers without
being forced to download the whole file -- and **especially**..where
I really notice this is trying to 'continue' an aborted download --
doesn't work with squid, the continuation process (example, 'wget')
tries to use a byte range to start from.

Either that or allow byte-ranged requests to pass through w/o
being cached?

It sounds like some (most?) of the compression support might already
be there? Not so much of a problem if it is uncompressed from
squid to me, as it's on a fast internal network, but any compression
of text on the way down to squid would really be helpful if it is
available. I notice the largest lag on sites with lots of small widgets.

I guess I was just surprised to read the roadmap and not see any
mention of progress toward HTTP 1.1 and didn't know if it was just
being done under the radar or not planned...

But I also understand about having full plates too...:-)

But if I don't ask or say something now and then...

Thanks,
-linda
Received on Mon Jan 11 2010 - 11:36:05 MST