Re: HTTP Protocol: How frequently should browser repeat requests after 304 responses?

[Eric Covener <co...@gmail.com>]

On Wed, Sep 17, 2008 at 4:46 PM, Manik Taneja <mt...@movik.net> 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?


-- 
Eric Covener
covener@gmail.com

Re: HTTP Protocol: How frequently should browser repeat requests after 304 responses?

[Eric Covener <co...@gmail.com>]

On Wed, Sep 17, 2008 at 5:16 PM, Manik Taneja <mt...@movik.net> wrote:
>>
>> Is there any room in HTTP/1.1 for the client or server to save on the
>> round-trips after the revalidation.

Darn, misread some headers and 2.0.x and 2.2.x update the Expires on
the 304 response.  Sorry.


-- 
Eric Covener
covener@gmail.com

Re: HTTP Protocol: How frequently should browser repeat requests after 304 responses?

[Manik Taneja <mt...@movik.net>]

On 18-Sep-08, at 2:21 AM, Eric Covener wrote:

> On Wed, Sep 17, 2008 at 4:46 PM, Manik Taneja <mt...@movik.net>  
> 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
> covener@gmail.com