Jonas J�rgensen wrote:

> Darin Fisher wrote:
> 
>>Jonas J�rgensen wrote:
>>
>>
>>>Darin Fisher wrote:
>>>
>>>
>>>>we had a long debate on this and the fact of the matter is that we must
>>>>honor 'cache-control: no-cache' on back/forward.  this is unfortunate
>>>>because the spec would allow us to not do this, but unfortunately many
>>>>important web servers depend on this behavior, and would block mozilla
>>>>
>>>>from accessing their web servers if we didn't implement back/forward in
>>>
>>>>this manner.
>>>>
>>>>
>>>Why do they depend on this and why would they block Mozilla?
>>>
>>>I find this behaviour *extremely* annoying, both as an end-user (why
>>>doesn't the stupid back button work when I'm offline?!?) and as a
>>>webmaster (I store some data in the session cookie when this page is
>>>loaded, therefore we will get into trouble later if this page is
>>>retrieved from cache, but I can't send a header telling the browser not
>>>to cache it 'coz then the friggin' back button won't work!!!).
>>>
>>>/Jonas
>>>
>>>
>>i find this requirement extremely annoying.  and it was only until very
>>recently that mozilla started to respect 'no-cache' on back/forward.  my
>>original implementation tried to make back/forward use the cache as much
>>as possible, but we got resistance from several major online banks.
>>those banks blocked mozilla and netscape 6x until this problem was
>>"fixed" to conform with other popular web browsers such as IE and
>>Netscape 4x.  until mozilla has some pull in the real world, we can't
>>really fight this accepted standard.
>>
> 
> Tell those banks to use Cache-Control: no-store instead. Doesn't that
> work with IE, Opera, etc?
> 


that would solve this problem, but it then prevents the user from saving 
the page or viewing the source of the page without refetching the page 
from the server.  if the page is the result of a credit card transaction 
the user would be out of luck.

darin



Reply via email to