[squid-users] Re: RFE - HTTP 1.1 RANGES

Amos Jeffries wrote:
> Linda W wrote:
>> 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.
>
> Not sure which roadmap you are looking at. HTTP/1.1 is on the TODO list
> of Squid-3.
> http://wiki.squid-cache.org/RoadMap/Squid3#TODO
> http://wiki.squid-cache.org/Features/HTTP11

---
	I found it later...it was a little bit buried?  :-)
> 
> A lot of the little details have been done quietly. Such as fixing up 
> Date: headers and sending the right error status codes, handing large 
> values or syntax in certain headers correctly.
---
	Wondered about that. My experience is that entities wouldn't 
tend to want to fund such work as standards adherence is often considered
something that should just 'be there'.
> I've started working on some experiments towards Expect-100 support 
> recently, but its early days on that.
---
	That looks pretty messy...
>
>> Ranges, it seems to me, could be kept in a binary-sized linked-list of 
>> chunks corresponding to the content downloaded
>> 'so far'. ... 
> 
> Nice ideas. The range support AFAIK has always been stuck up on detail 
> of storing ranges.
---
	I wondered about that -- it stuck in my head for a long while as well, until I thought that the problem was similar to how XFS stores files (power-of-two sized 'extents') and how a file could also be 'sparse' .. seemed like a general idea that might be matchable to the content caching issue.
> A storage engine matching that spec above it would be very welcome.
---
	Don't hold your breath on my account.  I have limited use of hands
and wrists, so while they occasionally allow some programming, I can be the
somewhat indelicate if I get caught up in a programming task.  I have to
arrange my computer work to not overfocus on any one task so my body parts
get a chance to rest -- and even then it's easy for my head to get ahead
of my body's limits.  Usually tolerable, except when I get too jazzed about
something, then it's really an annoying drag.  Result is unpredictability
in getting anything done in a time frame, and no, I'm not working. ;^).
> For 3.1+ a third-party eCAP module exists for gzip/deflate compression 
> in-transit of body content. That can use either eCAP or ICAP to do the 
> compression.
---
	That's a good for me to be trying a 3.1 build and not just a latest 3.0. 
Linda