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

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.


PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to