[bug] Cache-Control header op de post pagina

[Jero]

Mijn muis heeft een back button. Tijdens het posten kan het soms voorkomen dat ik daar per ongeluk op druk, dus druk ik op de forward button om terug te gaan naar m'n post die ik aan het schrijven was. Door de Cache-Control header wordt m'n browser echter gedwongen om de pagina te herladen waardoor mijn post verloren gaat. Dat kan erge frusterende gevolgen hebben als iemand net een post met een lengte van 3 kilometer had gemaakt, zoals je misschien kan voostellen.

[moto-moi]

IE zeker? Want in Firefox heb ik dat probleem nooit.

[Glaanie]

Heb hier hetzelfde probleem, hoewel het voor mij persoonlijk niet echt een probleem is (Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4).

@moto-moi: Gebruik jij toevallig een van de Beta's en is dit wat Jeroen en ik hebben 'gewoon' een bug in de browser?

[Jero]

Nee hoor, ik gebruik gewoon Firefox 1.5. En Glaanieboy, dit is geen bug. De waarde van Cache-Control is namelijk dit:

code:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Dit zorgt ervoor dat de browser de pagina niet mag opslaan in haar cache waardoor de pagina opnieuw moet worden geladen elke keer als deze wordt geopent.

[Glaanie]

Aha. Twas meer omdat moto-moi aangaf geen problemen te hebben...

[DaannO]

Jero schreef op zondag 25 juni 2006 @ 18:34:
Nee hoor, ik gebruik gewoon Firefox 1.5. En Glaanieboy, dit is geen bug. De waarde van Cache-Control is namelijk dit:

code:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Dit zorgt ervoor dat de browser de pagina niet mag opslaan in haar cache waardoor de pagina opnieuw moet worden geladen elke keer als deze wordt geopent.

Idd, dit betekent dat dus dat got deze waardes heeft ingevoerd en dat het probleem dus daar ligt. Dit is idd een vervelend probleem waardoor ik menig ts heb verloren

[Spider.007]

Jero schreef op zondag 25 juni 2006 @ 18:34:
Nee hoor, ik gebruik gewoon Firefox 1.5. En Glaanieboy, dit is geen bug. De waarde van Cache-Control is namelijk dit:

code:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Dit zorgt ervoor dat de browser de pagina niet mag opslaan in haar cache waardoor de pagina opnieuw moet worden geladen elke keer als deze wordt geopent.

quote: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.

Het is echter erg lastig om hier een implementatie van te maken die voor iedere situatie goed is. Hoe weet de browser of de waarde van de input ondertussen niet verandert is? Firefox doet dit redelijk goed; voor lege inputs laat hij de ingevulde data staan; maar voor voorgevulde inputs (zoals de update_message pagina) haalt hij de ingevoerde data weg. Het heeft niet alleen maar voordelen om de caching minder agressief te maken op dat punt (alhoewel de must-revalidate er wellicht uitkan voor update_message) en hem nog steeds voor alle situaties correct te maken (wat als een mod inmiddels een modbreak heeft gedaan; of je post heeft getrashed?)

[Jero]

Ok, you win. Maar dat neemt niet weg dat het irritant is.

[crisp]

Firefox doet dit goed, in ieder geval voor insert_message en de quickreply voor zover ik kan beoordelen. Voor update_message lijkt het me ook minder noodzakelijk.

Verder zegt de uitleg van Spider.007 wel genoeg lijkt me; hier is geen perfecte oplossing voor die werkt in iedere situatie.