|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Mark Swanson wrote:
Our emails crossed paths and we took 2 different approaches.
Yeah...this list has a bit of lag to it.
Actually I was only sending it when there was a gzipped resource -- I'm gathering this is wrong. :)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).
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.
[Older Fedora Users Mail] [Home] [Fedora Legacy] [Fedora Desktop] [iPod Nano] [ATA RAID] [Fedora Bible] [Fedora Marketing] [Fedora Mentors] [Fedora Packaging] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools] [Fedora Docs]