Re: Back button problem

You probably missed the section where the questioner describes that the same
senario works perfect when the gzip is disabled.

You of couse right that Server.Transfer does nothing in the client side, but
any way it happens as a travel to the server, and you should (and does when
gzip is disable) get another entry in the history.

it is right too that this entry will have the same page as the user
requested and not the page he actually got, but still it should (and does...)
give the option to go back to the previous page.

So, please read the question again, and I'll too will be happy to get an
answer to the question.

"Kevin Spencer" wrote:

> The Back button in a browser is linked to the client-side history. Using
> Server.Transfer does nothing on the client. It transfers the current Request
> to another Handler.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> You can lead a fish to a bicycle,
> but it takes a very long time,
> and the bicycle has to *want* to change.
>
> "Roy" <roy@xxxxxxxxxxxxxxx> wrote in message
> news:O$SPX3uDGHA.1384@xxxxxxxxxxxxxxxxxxxxxxx
> > Hi we have a following simple scenario in our application:
> >
> > 2 pages, one have a asp:Button control ,when server event onclick is
> > called we execute Server.Transfer and transfer the user to the second
> > page.
> >
> > It's works great if compression in IIS is disabled but if compression is
> > enabled we encounter following problem:
> >
> > When user clicks on "Back" Button in a browser it's don't really takes
> > user back but just reloads currently displayed page from the cache, and
> > second click on the "Back" button takes user two pages back. This scenario
> > is 100% reproducible.
> >
> >
> >
> > Can you explain this behavior ?
> >
> >
> >
> > We using .net 1.1 installed on Win2003 server, attached is description of
> > our configuration procedure for enabling GZIP on IIS 6.0
> >
> >
> >
> >
> >
>
>
>
.

Loading