<div class="gmail_quote">On Tue, Feb 17, 2009 at 12:47 PM, Archie Cobbs <span dir="ltr"><<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div class="Ih2E3d">On Mon, Feb 16, 2009 at 2:08 PM, Doug Campbell <span dir="ltr"><<a href="mailto:voiceglue@campbellcastle.com" target="_blank">voiceglue@campbellcastle.com</a>></span> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The problem comes in determining which audio fetches are<br>
static and which are dynamic.<br>
<br>
While I would like to be able to determine static versus<br>
dynamic audio fetches by examining the server HTTP headers<br>
Expires: <now>, Cache-Control: no-cache, Cache-Control:<br>
private, and Cache-Control: s-maxage=0, I cannot wait for the<br>
server response as by then it is too late to have sent cookies.<br>
<br>
So, I propose determining static audio fetches as those having<br>
a VXML maxage attribute (or audiomaxage property if not defined)<br>
not equal to 0. Conversely, dynamic audio fetches have maxage<br>
set to 0. This gives the VXML script author full control over<br>
whether to use the shared cache for any particular audio resource.</blockquote></div><div><br>I'm not an expert on this stuff, but surely there exists a "correct" answer that is in accordance with the HTTP protocol.<br>
<br>For example, what does Google send with their logo image when you go to their search page?<br><br>Also, I don't understand the problem described in the second paragraph above. I.e., you seem to believe that the Expires and Cache-Control headers are limited in "scope" to requests with the same cookie. But I think this is not true. The cookie mechanism is independent from the cache control stuff. So you should be able to just send the cookies always, and then do whatever the headers tell you do about caching when you get the response. If you request the same URL with different cookies, and the result was previously (correctly) cached, then you should be able to just use it. If that's wrong then it's not your fault, it's the HTTP server's.<br>
</div></div></blockquote><div><br>Some relevant links....<br><br><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44">HTTP Vary header</a><br></div></div><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">Caching in HTTP<br>
</a><br> I think the Vary header is what you should pay attention to, at least "in theory".<br><br>-Archie<br clear="all"><br>-- <br>Archie L. Cobbs<br><br>