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

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

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 :).

best,
M


On 18-Sep-08, at 1:30 AM, Dan Poirier wrote:

> I've looked at mod_expires doc and RFC 2616, but can't really
> tell what the right behavior is supposed to be in this case.
>
> Using mod_expire to set the expiration time to something like
> "access plus 1 hour", we see a browser request a file, get back
> a 200 with the expiration, and not request it again for an hour,
> as expected.  The next time, it uses an if-modified-since and
> gets back a 304, also good.  But from then on, it keeps coming
> back to the server every time and getting back 304's.
>
> The 304 responses won't have any cache control information, of
> course, per RFC 2616 10.3.5.
>
> Two questions:
> 1) Is the browser behaving properly, or should it wait another hour
> after each 304 before making another request?
>
> 2) If the browser behavior is right, is there a way to configure
> Apache to tell the browser to only check once an hour instead of
> every time?
>
> Thanks.
>
> -- 
> Dan Poirier <po...@pobox.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

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