What smarts in particular?
I think the only range smarts in the
* http client side code should be decoding range requests & creating
single and multi range responses.
* http server side code should be converting a generic range request to
an upstream http range request, and converting http range responses to
generic responses
* likewise for the ftp server side code.
I have a signficant chunk of this done in rbcollins_filters.
From what Henrik and I were bouncing around last week, we need to build
up the intermediary outside the store, and get the store to support the
generic concepts.
If you are preparing to modify the store code support range data and
headers as metadata then go for it. I'm getting ready to pick up the
gauntlet for putting an intermediary together for the content_processing
branch. (rbcollins_filters was turning into a hack job because I was
working around the design issue..
Rob
----- Original Message -----
From: "Adrian Chadd" <adrian@creative.net.au>
To: <squid-dev@squid-cache.org>
Sent: Wednesday, February 21, 2001 9:19 PM
Subject: handling ranges in squid-modio
>
> Hi,
>
> So can I get closure on this? Do people think its a good idea if
> I remove the existing range smarts from the http client/server
> and ftp code and wait until the storage layer is reimplemented ?
> I can see quite a bit of complexity sitting in the http header/acl/
> client_side code.
>
> This isn't arequest to rip out the range support completely, its
> more of a request to rip it out in the hope that its reimplemented
> differently (ie through the store or at a different layer in the http
> server code, rather than everywhere..)
>
> What do peple think?
>
>
> Adrian
>
> --
> Adrian Chadd "Romance novel?"
> <adrian@creative.net.au> "Girl Porn."
> - http://www.sinfest.net/d/20010202.html
>
Received on Wed Feb 21 2001 - 13:34:51 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:33 MST