RE: transfer-encoding

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Friday, 5 January 2001 5:09 PM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: transfer-encoding
>
>
> Robert Collins wrote:
>
> > orgin server -> our upstream socket
> > socket to fs layer
> > fs layer->list of listening clients
>
> No. More like:
>
> origin server -> our upstream socket
> socket -> memory cache
> memory cache -> list of listening clients
> memory cache -> fs layer
> listening client -> client socket

Ahh. This is still code I'm only starting to come to grips with.

Does this approach sound better then
* Provide a set of generic te routines
* Have the fs layer use the routines to get whatever format it wants to
save (Needed so switching te modules on and off doesn't invalidate the
cache)
* Have client_side use the routines to get whatever format it wants to
send
* Ignore what happens to the incoming data per se (for now).

> If you make the API modular with a configure option for which
> encodings
> to enable I see no need to have separate branches. But if you really
> want to sure.

Yes I do - here's my reasoning...
I've found while working on the auth_rewrite stuff, that large scale
changes have a tendency to break dependant modules temporarily. I.E.
adding in a require module function. Personally, while I'm testing a new
idea out, I don't want to be breaking everything in sight until it's
stabilised - even if that's only a few hours work.

For example, Digest auth required adding additional headers and
potentially trailers to the outbound requests. Doing that required
changes to the auth module API code & client_side & errorpage. Nothing
major but I was able to get it going in isolation, using CVS along the
way. (As per your CVS suggestions Henrik :-]).

Then when I was done, I simply picked up the API level changes,
committed them to auth_rewrite and merged back down.

Rob
Received on Thu Jan 04 2001 - 23:47:58 MST