On 18-Sep-08, at 2:21 AM, Eric Covener wrote:
On Wed, Sep 17, 2008 at 4:46 PM, Manik Taneja <[EMAIL PROTECTED]>
wrote:
this behavior seems highly browser dependent. There may be a few
possibilities as to why the browser doesn't send an IMS request.
a. the browser cache is cleared
b. the browser has a limited size cache and so this object gets
ejected due
to lack of space. you could try increasing the size of the browser
cache and
see if that helps.
c. the browser prolly follows some algorithm where by it decides to
send an
IMS only once, unlikely, but I am just guessing.
d. the browser is IE and is buggy :).
I think in Dan's case the problem is that the IMS validation never
gives the opportunity for a "new" expires time to be communicated to
the client:
0) Browser gets a 200 responds for a static file along with an
Expires header
1) the browser happily uses it's local copy during the Expires window
2) Expires time is up
3) browsers sends a request with IMS
4) server responds with a 304
5) It would sure be nice if the browser had some way to find a new
Expires: time, because now every subsequent request for the static
file is a round-trip to get the 304.
Is there any room in HTTP/1.1 for the client or server to save on the
round-trips after the revalidation.
I speak on behalf of a proxy cache and in the past I would send out a
304 along with a new expires header when the client sent an IMS for a
cached response.
apparently someone reported a similar issue for squid.
http://www.squid-cache.org/bugs/show_bug.cgi?id=7
I wonder what prevents a server from sending a 304 along with new
expires header, what i mean is that this behavior would be no
different from the case where a reverse proxy for a particular server
sent back a 304 response. The client is mostly unaware of the reverse
proxy, unless indicated by the X-forwarded-for or Via headers but
apart from that client shouldn't care who sent back the response.
-M
--
Eric Covener
[EMAIL PROTECTED]
