Re: Code updates

Our emails crossed paths and we took 2 different approaches. 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.

What you have done or what I have done work well enough for me and I'm happy 
to leave it at that.

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.

Since Ingo is on a sebatical (?) people will simply have to decide what is 
best for them and apply which patch suites them best.

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.

Cheers.

On November 15, 2002 10:26 pm, Miles Elam wrote:
> Thanks for testing that Mark.  I really appreciate it.  Here's the new
> updated diff of net/tux/proto_http.c with the "Vary" header: a very
> simple change.  I don't have access to a proxy server like squid, so
> will someone give this a test?  It works for me, so you can be pretty
> sure that it won't crash your machine outright.  Well...Let me rephrase
> that lest someone miscontrues that as a written promise and sues me.  I
> make no guarantees.  But if it crashes, I will be more surprised than
> you, and you can always get back to stable by turning off compression
> support.  :)
>
> - Miles
>
> ---------------------------------------------------
>
> 1854c1854
> < #define HEADER_PART3A "\r\nContent-Encoding: gzip"
> ---
>
>  > #define HEADER_PART3A "\r\nVary: Accept-Encoding\r\nContent-Encoding:
>
> gzip"
> 1961,1963c1961,1973
> <             // "%d" req->total_file_len
> <             memcpy(curr, &req->etag, req->lendigits);
> <             curr += req->lendigits;
> ---
>
>  >             /* The ETag was generated with an uncompressed file's
>  >              *  info.  I've left the ETag as it is, but the size
>  >              *  needs to be from req->total_file_len.  In other
>  >              *  words, needs to be from the compressed image if
>  >              *  we're sending gzip versions.
>  >              *  - [email protected] -- 2002-11-13
>  >              */
>  >             if (req->content_gzipped)
>  >                 curr += sprintf(curr, "%Ld", req->total_file_len);
>  >             else {
>  >                 memcpy(curr, &req->etag, req->lendigits);
>  >                 curr += req->lendigits;
>  >             }
>
> --------------------------------------------
>
> Mark Swanson wrote:
> >Perhaps all we need to do is modify the patch to also send back the
> > header: "Vary: Accept-Encoding"
> >
> >http://lists.over.net/pipermail/mod_gzip/2002-September/006474.html
> >
> >Thoughts?
>
> _______________________________________________
> tux-list mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/tux-list

-- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/