Re: Code updates

[Miles Elam <miles@pcextremist.com>]

Mark Swanson wrote:

> Our emails crossed paths and we took 2 different approaches.
Yeah...this list has a bit of lag to it.

> You are forcing Vary: on all responses, and I'm only sending it when people access it via the extra_html_header (which needed patching).
Actually I was only sending it when there was a gzipped resource -- I'm 
gathering this is wrong.  :)

> Perhaps the perfect patch would be another proc entry to enable/disable the 
> Vary: header.
I would think it would be better tied to other items.  For example, if 
compression enabled, it always sends "Vary: Content-Encoding".  Leaving 
it as an extra proc entry just invites problems for when people turn on 
compression but don't know about "Vary";  This is likely as we didn't 
really know about it twenty four hours ago and I like to think that we 
are fairly saavy users.

In the future, if TUX supports any type of client detection, a "Vary: 
User-Agent" will have to be sent as well.  If this functionality is 
handled by the implementation, they can be effectively  processed and 
concatenated without user head-scratching;  The user would only have to 
worry about the end result and not the means to get there.

> What you have done or what I have done work well enough for me and I'm happy 
> to leave it at that.
Is there an established location for code updates or is this list the 
"repository" until Ingo returns?  I'd hate for someone to waste time 
trying to re-fix this bug.

> Last thought: If squid _ever_ caches a response with no Vary it will not 
> replace it with a new response containing Vary - nor obey the Vary semantics. 
> So, perhaps it is simply better to always enable Vary: so this confusing 
> scenario can never occur.
Which means that my last patch was incorrect -- It should always be 
sending a "Vary" header or else it is no better than its absence 
altogether.  As for Squid's dismissal of "Vary" if a previous request is 
not "Vary"ed, that sounds to me like a Squid bug.

> Since Ingo is on a sebatical (?) people will simply have to decide what is 
> best for them and apply which patch suites them best.
This is fine, but again, is there a common drop-off spot for patches?

> One more thought:_) My method uses up the extra_header - which can only be 
> used for a single header insertion as you can't (I couldn't) insert more than 
> on '\n' in a /proc/sys/net/tux/extra_html_header entry.
I'm happy to hear that it works for you, but having users manually set 
TUX header values strikes me as a bug waiting to happen.  It's extremely 
flexible, but is the flexibility warranted?  It seems to me like an 
implementation detail -- not the user's domain.

- Miles