Re: Code updates

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