I've stopped using Server.Transfer

[Andy Fish]

Hi,

I just thought someone reading this might be interested to know that I've
just decided to stop using server.transfer and replace it with
response.redire ct instead.

The app had several places where you would click on a button, it would go
away and do something and take you to the next page. When I first started
using asp.net I was keen on server.transfer because it avoids an unnecessary
round trip to the browser. However, the downsides of this approach are:

1. URL as shown in the browser does not correspond to the page the user is
actually seeing.

2. if he refreshes the new page this has to be done by re-posting the
previous page. This may cause problems on the server if the action is not
idempotent, but at the very least will cause a warning from IE about having
to post

3. if the new page and old page are in different directories, any relative
references to external resources (e.g. <img src="../images/foo.gif">) in the
new page won't work because the URL seen by the browser is the old one

I realise that 2 and 3 are side-effects of 1. For my money, unless you want
to read the form values from the old page in the new one, you're better off
living with the extra network traffic and doing a redirect.

Andy

[Peter Rilling]

I agree. I have never used Server.Transfer for the vary reasons that you
specify. It is not that much work for the browser to follow a redirect
command.
"Andy Fish" <aj****@blueyon der.co.uk> wrote in message
news:OT******** *****@tk2msftng p13.phx.gbl...

Hi,

I just thought someone reading this might be interested to know that I've
just decided to stop using server.transfer and replace it with
response.redire ct instead.

The app had several places where you would click on a button, it would go
away and do something and take you to the next page. When I first started
using asp.net I was keen on server.transfer because it avoids an unnecessary round trip to the browser. However, the downsides of this approach are:

1. URL as shown in the browser does not correspond to the page the user is
actually seeing.

2. if he refreshes the new page this has to be done by re-posting the
previous page. This may cause problems on the server if the action is not
idempotent, but at the very least will cause a warning from IE about having to post

3. if the new page and old page are in different directories, any relative
references to external resources (e.g. <img src="../images/foo.gif">) in the new page won't work because the URL seen by the browser is the old one

I realise that 2 and 3 are side-effects of 1. For my money, unless you want to read the form values from the old page in the new one, you're better off living with the extra network traffic and doing a redirect.

Andy