Why does Transfer hide the target page's address?

[dee]

Hi,
I'm curious why MS decided to have Transfer hide the target page's url
invisible?
Any guesses ?
Thanks.
Dee.

 

[Peter Rilling]

Microsoft did not decide anything, it is just the behavior of the server.

On a Redirect, a command is sent back to the browser and it is the
responsibility of the browser to redirect to the location. On a Transfer,
no server-browser interaction happens. The server just simply executes
different code, but the browser has no way of knowing that because it never
receives any signal from the server. The browser does not care what code
executes on the server as long as it receives some HTML.

This is one reason that I will not use Transfer (although it has its
purpose, but not very often).

 

[Marina]

Because in this case the browser doesn't get notified that a redirect
occurred. It thinks it received the page originally requested.
If you want the new page's URL to show up, use Response.Redirect. This
informs the browser of the redirect.

 

[dee]

Thanks Marina,
Does redirect involve one extra trip to the server?

 

[dee]

Thanks Peter,
What would be the advantage of using Transfer?

 

[KMA]

Precisely because it hides the URL. Imagine you have dynamically created
pages. The URLs don't represent actual pages on your server. You intercept
the request for a non-existant URL and return your dynamically created page.
The browser still shows the expected URL, and not the URL of the page that
actually did the work.

eg User clicks on link
www.myshop.com/household/electrical/cleaning/vacuum/Hoover/Dustmaster5000.as
px

which doesn't exists. Your code looks in the database for the product
details and sends back html. Users' browser still shows the fake URL.

Another reasonto use transfer is to reduce round trips.

 

[dee]

Thanks KMA
If user clicks on non-existing page url doesnt he get a 404 error?

 

[Mythran]

Hi,
I'm curious why MS decided to have Transfer hide the target page's url
invisible?
Any guesses ?
Thanks.
Dee.

It executes another files code.


Server.Transfer requires no extra round-trip.
Response.Redirect does.

You use, as an example, Server.Transfer to transfer to another page when an
exception occurs so you can show a proper exception. If you use
Server.Transfer, you can use Server.GetLastError() to get the exception that
was thrown. If you use Server.Redirect, you cannot. That is one useful
reason why you would use Server.Transfer

HTH,
Mythran

 

[Jeremy Ames]

Technically, the page KMA listed does exist. It is just a "worker" page that
does nothing but processing, and it sends you to the correct page once
processing is complete. That is generally what you would use a transfer for.

 

[Colin Peters]

Yep. but the method I describe involves catching the 404 with a custome
error page. this custom error page looks at the requested url which is
passed as a parameter and, for example, does a db lookup on Dustmaster5000.

the nice thing is that you can tailor the url "pseudo sub directories"
as much as you want. Different languages for instance. Without actually
having to create the whole directory tree. also some search engines
attach relevance to the URL components.

I don't see how you can create a (maintainable) large website any other way.

 

[Peter Rilling]

This has nothing to do with Transfer. For this you would use HttpHandlers
(or whatever it is named).

For Transfer you would still have to have the physical page out there,
right? You still would do something like
Page.Transfer("MySecondPage.aspx").

 

[dee]

Why would you create pseudo directories?

Yep. but the method I describe involves catching the 404 with a custome
error page. this custom error page looks at the requested url which is
passed as a parameter and, for example, does a db lookup on
Dustmaster5000.

the nice thing is that you can tailor the url "pseudo sub directories" as
much as you want. Different languages for instance. Without actually
having to create the whole directory tree. also some search engines attach
relevance to the URL components.

I don't see how you can create a (maintainable) large website any other
way.

 

[KMA]

It does have to do with transfer.

Look at the example I give. The page URL doesn't exist, but it is what the
client sees in the address bar. A custom 404 page catches the error due to
non-existant page, strips off the end bit and produces a page of output
using the Dustmaster5000 details from a db.

So the custom 404 has something like:

Transfer("DynamicCreate.aspx?Dustmaster5000");

If you just redirect then the client issues a second request and his address
bar changes.

 

[KMA]

2 reasons.

1) like I said, some search engines attach relevance to the URL components.
2) it hides the real directory structure from malicious view
3) it obviates the need for pages like:
www.myshop.com/ProductDetails.aspx?ProductID=Dustmaster5000

4) you can have different pseudo directories dependent on local language.

 

[dee]

Thanks K that explains it.
I have a problem using Transfer though. I transfer to a page and the address
bar still shows the source page. Thats fine. But now I do postback and then
not only the add bar reveals the true address but also there is
inconsistancy since they first time browser received the page the add bar
didnt indicate it.

 

[Alan Silver]

This has nothing to do with Transfer. For this you would use

HttpHandlers (or whatever it is named).

Actually, you don't needs those at all, you only need to use the
UrlRewrite method. For some reason I've never worked out, this extremely
simple and very useful technique is made horribly complex in almost
every article and sample going by using handlers.

As long as the fake URL ends in .aspx, it will be handed to ASP.NET for
processing. You just add code to your global.asax to check for the fake
URL and use UrlRewrite to call the real page. The browser still shows
the fake URL.

HTH