Re: Want to avoid 304 error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks again, Joshua.
You are right, it's my application that set 'must-revalidate' header. But it's not the problem, I've deleted it and all works exactly the same. I suspect the 304 return code is the reason because Firefox set '1970-01-01 01:00:00 (already expired)" expiry date, and not that header. I've found a "half-solution". If I use a 'Header append Cache-Control "max-age=something"' , Apache inserts this header in response, even if return code is 304 (until now I've used only 'ExpiresByType' to set cache-related headers). In this case, if Internet Explorer 6.0 receives max-age header, it updates correctly cache-entry expiry time, but Firefox still updates it to '1970-01-01 01:00:00 '. I'll search a litte more....
Thanks,

Sergio



Joshua Slive escribió:
On 7/23/07, Bello Martinez Sergio <serbel@xxxxxxxxxx> wrote:
Thank you for your respose.
I've checked that browsers don´t work as you say they're supposed to
work. When Apache aswers with a 304 response, the only cache-related
header it includes by default into the response is 'Cache-Control:
must-revalidate'.
Internet Explorer 6.0 does nothing with it, after receiving this
response, cache remains the same (entity expiry dates remains the same)
so each time browser needs those elements, it sends a new http request
an it receives a new 304 response. In the case of Firefox 2.0, the cache
is updated, but not in the way I'd like: instead of this, entity's
expiry date are updated to '1970-01-01 01:00:00', so the result is the
same, each time the browser needs one of these elements, we have a
request-304 response (with a worse performance)

must-revalidate is certainly not something that apache returns by
default or with the default handler. In fact, no cache-control
parameters are set by default. So I think you need to examine your
application.

Although must-revalidate should technically not effect the caching
decision of the client in most cases, it is a widely abused parameter
and it wouldn't surprise me at all if clients treat this as marking
the response as instantly stale. I would therefore guess that your
problem would be eliminated if you dropped this parameter.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux