[hunchentoot-devel] HTTP 304 behavior (was Re: ETag, Cache-Control, and/or Expires headers)

[Patrick May]

On 6 Jul 2009, at 20:24, Patrick May wrote:
> 	I need to prevent an intermediate cache from caching a static audio
> file I'm providing via register-static-file.  What's the easiest way
> to set these for every reply (changing it dynamically, in the case of
> ETag)?

	I got some feedback from the maintainer of the intermediate cache  
that might be of interest.  The problem I was seeing was that the  
intermediate cache wasn't understanding the type of the audio file I  
was serving.  Both wav and mp3 formats were affected.  It turns out  
that Hunchentoot sends a Content-Type header with a 304 (not modified)  
response.  Apache and other common servers don't.

	RFC2616 section 10.3.5 says:

"If the conditional GET used a strong cache validator (see section  
13.3.3), the response SHOULD NOT include other entity-headers.  
Otherwise (i.e., the conditional GET used a weak validator), the  
response MUST NOT include other entity-headers; this prevents  
inconsistencies between cached entity-bodies and updated headers."

Does this mean Hunchentoot is non-compliant?

Regards,

Patrick