httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ics.uci.edu>
Subject Re: pr#4118: MSIE 4.0 screws up with Vary
Date Wed, 21 Apr 1999 23:30:31 GMT
>So the main problem is the fact that the Vary stuff actually is a list
>representing a _set_ of header fields and not just a list representing an
>_array_, but it's encoded as a _string_. And dealing with a set encoded as a
>string is nasty. To avoid redundant handling of this I suggest we do the
>following:
>
>1. We add a true "table *vary" (or for optimization reasons 
>   just an "array_header *vary") to the request_rec where modules can insert
>   their Vary fields.
>   
>2. The actually "Vary: foo,bar,quux" header in
>   request_rec->headers_out("Vary") is generated at the end out of the
>   request_rec->vary with the help of a single ap_array_pstrcat() call inside
>   the main code.

Yes, that is how I would do it too, and special-case the handling of
Vary in the SetHeader and util_script.c code.  I suggest adding helper
functions to http_protocol.c:

  API_EXPORT(void) ap_add_to_vary(request_rec *r, const char *fieldname)
  API_EXPORT(const char *) ap_vary_string(request_rec *r)

and then add something like

   if (r->vary && (vs = ap_vary_string(request_rec *r)) != NULL) {
       ap_table_setn(r->headers_out, "Vary", vs);
   }

to ap_send_http_header().  It would also have to be promoted when a
subrequest is used for a response.

Alternatively, we could fix table_merge so that the fields are split
before merging, but that would have a significant performance hit.
Of course, the right thing to do is to replace these things with more
efficient tokens and a data structure that understands set operations.

....Roy

Mime
View raw message