Thoughts on maintaining Vary

[Rodent of Unusual Size <Ke...@Golux.Com>]

There's an open PR (1644) about the fact that URL rewriting
based upon the request header fields doesn't get
reflected in the setting of the response field Vary.
(The PR is specifically about mod_rewrite, but the issue
is wider than that.)

I think the two main places this sort of thing happens are in
mod_rewrite and the various envariable conditionals.  I've
been giving this the odd cerebral cycle, and one weak idea
I've had about the latter was to potentially attach an array
to each envariable.  If it gets modified based upon request
fields, the array would be attached and the field name involved
would be added to the array.  Elsewhere, in the code
that makes decisions based upon envariable settings, if an
envariable was used to determine something then the contents
of the associated array would be merged into the Vary field in
r->headers_out.

Just my thoughts on the subject so far..  I don't like them too
much, because it seems to be a special case of a more general
solution, but I wanted to bounce the idea off others.  This
specific implementation might be horrible performance-wise,
but as a basic concept..

#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

Re: Thoughts on maintaining Vary

[Rodent of Unusual Size <Ke...@Golux.Com>]

More random thoughts on this..

mod_rewrite needs to be handled specially because it does a lot
of its header field-based work directly.  However, it also uses
envariables to make decisions, including envariables that are
set according to header field values.

mod_access is the only other [standard] module that makes
decisions based upon envariables.  (Aside from protocol
labelling, which doesn't count.)  mod_setenvif and mod_rewrite
are the only ones that set envariables based upon header field
values.

So here's another approach, specifically aimed at the envariable
case:

Add a envar->fieldname(s) table to the request_rec.  When something
sets an envariable based upon a request header field, it does a

    table_add(r->envar_vary, envar, fieldname);

And when something makes a decision based upon an envariable's
setting, it does a

    if ((v = table_get(r->envar_vary, envar)) != NULL) {
        table_add(r->headers_out, "Vary", v);
    }

These activities would actually be put into routines in
http_request.c so that modules would only need to add a single
call for each activity.

Again, at the moment this only means mod_access and mod_rewrite.
But who knows what else may turn up, either in 3p modules or our
own stuff in the future.. we had quite a fad for envariable
conditionals a while ago.

I still don't like this much; it seems like a lot of overhead.
And I haven't even looked at the subrequest issues yet.  On the
other hand, anything involving the use of envariables is already
pretty high overhead, and (I expect) by far the exception rather
than the rule, so I think the extra work for the sake of 2068
correctness is probably acceptable.

#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>