Search squid archive

Re: RFE - HTTP 1.1 RANGES

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux