Andi Gutmans wrote:
> I suggest you merge this into 4.0.5 because it seems to me
> that otherwise output buffering will be quite a mess without
> it. It would be a shame to release 4.0.5 without it.
Ok, done.
> Your fix looks OK but I'd like to hear the opinion of someone
> else who is more familiar with RFC2616.
Hope I didn't jump the gun with the merge (read this mail right after the
commit).
Here is the relevant excerpt from the RFC:
13.6 Caching Negotiated Responses
Use of server-driven content negotiation (section 12.1), as indicated
by the presence of a Vary header field in a response, alters the
conditions and procedure by which a cache can use the response for
subsequent requests. See section 14.44 for use of the Vary header
field by servers.
A server SHOULD use the Vary header field to inform a cache of what
request-header fields were used to select among multiple
representations of a cacheable response subject to server-driven
negotiation. The set of header fields named by the Vary field value
is known as the "selecting" request-headers.
When the cache receives a subsequent request whose Request-URI
specifies one or more cache entries including a Vary header field,
the cache MUST NOT use such a cache entry to construct a response to
the new request unless all of the selecting request-headers present
in the new request match the corresponding stored request-headers in
the original request.
Note that the current PEAR implementation of HTTP::Compress sends exactly
this Vary header also, and works great.
Anil
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
