[asp.net 2.0]Voorkomen van 'Page expired'

[sopsop]

Ik heb een pagina (P1) met daarin een gridview . Deze gridview is sorteerbaar en gepagineerd. In de gridview zit een column met commandbuttons die doorlinken naar een andere pagina (Pagina 2) die alle verdere details van dat record weergeeft. So far so good.

Stel ik ben op P2 gekomen door direct na het openen van P1 op de button van een row in de gridview te klikken. Als ik vervolgens op de back-button van de browser klik, werkt alles prima: ik krijg P1 gewoon te zien.

Nu het volgende: Ik doe eerst een of meerdere postbacks op P1 (sorteren van de gridview, andere gridviewpagina selecteren) en klik dan pas op een button van een row in de gridview om naar P2 te gaan. De back-button op P2 levert dan een fraaie Page expired melding op. Een refresh (F5) zorgt er dan voor dat de pagina wel correct wordt getoond.

Extra info: de site draait middels een SSL-verbinding (https), ik heb her en der wat teruggevonden dat dat ook van invloed kan zijn. De oplossingen hieronder werken echter ook niet met een 'standaard' http-verbinding.

Ik heb -uiteraard- flink lopen zoeken, maar tot op heden heb ik geen oplossing voor dit probleem kunnen vinden. De mogelijke oplossingen die ik gevonden en geprobeerd heb, maar niet tot het gewenste resultaat leiden:

Visual Basic .NET:

Response.Cache.SetAllowResponseInBrowserHistory(False)
Response.Cache.SetCacheability(HttpCacheability.Server)

Geen effect

Visual Basic .NET:

Page.SmartNavigation = True

Page.SmartNavigation is obsolete in 2.0 en zorgt ervoor dat de css van het postback gedeelte in P1 niet geladen wordt, het switchen naar P2 geeft zelfs een overflow error in de browser.

Ik ben me er van bewust de page-expired standaard gedrag is van de browser bij het teruggaan naar een pagina die een "post" naar zichzelf heeft gedaan. Ik ben dus op zoek naar een workaround. Die workaround mag ook bestaan uit het 'verwijderen' van de postback pagina's uit de browsergeschiedenis.

Iemand een idee hoe ik dit kan realiseren?

[ Voor 4% gewijzigd door sopsop op 05-09-2007 15:47 ]

[gorgi_19]

Geen postbacks gebruiken, maar via GET navigeren?

[sopsop]

gorgi_19 schreef op woensdag 05 september 2007 @ 16:17:
Geen postbacks gebruiken, maar via GET navigeren?

asp.net en geen POST gebruiken is volgens mij niet echt handig.

[gorgi_19]

sopsop schreef op woensdag 05 september 2007 @ 16:21:
[...]

asp.net en geen POST gebruiken is volgens mij niet echt handig.

Want? Voor de sorteermogelijkheid zie ik eigenlijk weinig problemen

[sopsop]

gorgi_19 schreef op woensdag 05 september 2007 @ 16:53:
[...]

Want? Voor de sorteermogelijkheid zie ik eigenlijk weinig problemen

Wel als je gebruik maakt van een masterpage met daarin een aantal auto-postback controls. Je server-side form-tag op method = get zetten werkt dan niet.

Of had jij een andere methode in gedachten?

[gorgi_19]

In dat laatste geval ga je er dan inderdaad niet makkelijk aan ontkomen nee

[st0p]

browser side caching aanzetten wil vaak wel helpen, weet niet hoe dat onder asp2.0 gaat maar onder php moet je een aantal headers meesturen. googelen op op browser caching moet wel wat bruikbaars opleveren.

[Verwijderd]

GET is bedoeld om gegevens mee op te halen. Daardoor kan een GET opnieuw worden uitgevoerd zonder dat er onbedoeld gegevens kunnen worden gewijzigd.

POST is bedoeld om gegevens mee te bewerken. Het opnieuw POST'en van gegevens kan hierdoor nare gevolgen hebben. Om dit af te vangen, vragen de meeste browsers of je de POST-gegevens opnieuw wilt versturen.

IE geeft om bovenstaande reden geloof ik een "page expired"-melding.

[Niemand_Anders]

Cache policy op public (HttpCacheability.Public) zetten ipv Server. De browser moet namelijk kunnen bepalen of de cache gebruikt mag worden. Als jij aangeeft dat de 'server' dit bepaald, kun je dus niet terug in je history omdat de browser (msie) niet weet of hij deze pagina wel mag tonen.

Letterlijk uit de MSDN documentatie (welke blijkbaar niemand meer leest):
Server: Specifies that the response is cached only at the origin server. Similar to the NoCache option. Clients receive a Cache-Control: no-cache directive but the document is cached on the origin server. Equivalent to ServerAndNoCache.
Public: Sets Cache-Control: public to specify that the response is cacheable by clients and shared (proxy) caches.

[sopsop]

Niemand_Anders schreef op vrijdag 07 september 2007 @ 13:42:
Cache policy op public (HttpCacheability.Public) zetten ipv Server. De browser moet namelijk kunnen bepalen of de cache gebruikt mag worden. Als jij aangeeft dat de 'server' dit bepaald, kun je dus niet terug in je history omdat de browser (msie) niet weet of hij deze pagina wel mag tonen.

Thanks, dit werkt!

Overigens vreemd want ik heb flink gezocht, heel veel soortgelijke problemen gevonden en blijkbaar dus maar één halve oplossing. Maar ik ben het met je eens dan ik MSDN wel even had kunnen napluizen toen bleek dat HttpCacheability.Server niet werkte.

_{hmmm. als ik de "HttpCacheability.Public" term in mijn zoekqueries bijvoeg zie ik wel ineens plenty oplossingen}

[ Voor 8% gewijzigd door sopsop op 07-09-2007 14:17 ]