response.redirect or server.transfer?

I was wondering which one would be the best to use between response.redirect or server.transfer? The faster? the "most secure"?

thanx a lot

Server.transfer is faster since the Response.redirect path involves a message traveling to the user's browser and a reply coming back before the target page is sent while the server.transfer path directly goes to the new page without the extra messages.

Secure? That isn't changed.

Here a good article about the advantages and disadvantages of server.transfer

http://www.15seconds.com/Issue/010220.htm

ok thank you guys... thank for the article raf:thumbsup: I'm gonna use server.transfer as long as it's not in a situation that might create a problem, in that case I'd use response.redirect.

You can't pass a querystring to the new page. (However, remember that the querystring passed to the page executing the transfer will automatically be passed along to the new page.) If you try to pass a querystring to the new page, you will trigger an ASP error.

So, I am unable to use:
<%Server.Transfer("page.asp?Query=String")%> ?

<EDIT>
I tested it, and NO! You can not give new information like that... too bad... I guess this method is usless to me...
</EDIT>

Thanx Morgoth... I think it will also be quite useless to me... + it seems not to take that a longer time to use response.redirect...

Well it depends what you could use it for.
I have a page that loads information into a database, now if your information is already in the database it redirects you. I changed that to server.tranfer.

If you are in the database Than
Transfer to the next page
Else
Put information in the database and show this page.
End If

And it's neat because it doesn't change the URL at all.
So I can only use this function once in my entire code, but I might find something else I will use it for later. ;)

Yeah. I believe there was someone around here, with a sign like : "To a man with only a hammer in his toolbox, every problem will look like a nail."
This server.transfer can realy be the best tool sometimes. Imagen you post a form to a page with method="get" (for instance from another application). You could then check on the referer or the value of a posted variable, and based on that referer/value, transfer to another asp-page where you actually process the form.

With response.redirect, you can't do that.

Raf, that quote is great :thumbsup:

Originally posted by Eskimo
Raf, that quote is great :thumbsup:
Iagree. I wish i made it up myself.

Hmm, you learn some new ideas every day. ;)

Originally posted by raf

This server.transfer can realy be the best tool sometimes. Imagen you post a form to a page with method="get" (for instance from another application). You could then check on the referer or the value of a posted variable, and based on that referer/value, transfer to another asp-page where you actually process the form.

With response.redirect, you can't do that.


mmmmmhhh... could you give a short example of this idea if you have time raf? sounds very interesting, but I'm not sure to fully get it.

Well, it sometimes happen that you have this form with 10 formfields and where you can perform different action with the data.
Insert a new record with these values. Or don't insert them but do some calculations and show the outcome (simmulations etc). Or update all recordsof that user with these values.

Now, you could tackle this with different tactict. You you use javascript and post the form to the page that is associated with that choice-formfields value.
Or you could post it to this 1 page and have all code for the three actions in this one file.
Or you could store the code for these files in seperate files and choose which file to include, depending on the choice.
But in most cases, including that code might be quite complex. Specially if you can also request these action from other pages.
Anyway, suppose that you have 3 seperate pages that perform the actions. These pages can also be requested by the client from other webpages (even from outside your site).
Then you (and the other applications) can use the get method (inside the from-tag. Like <form method="get"> ) to post the form to this first page, and in that page, you can check which choice
was made and then send all the data to this second page that processes it. Like
[code]
select case request.querystring("choice") 'suppose the dropdown where you could choose an action is caled "choice")
case 1
server.transfer("insert.asp")
case 2
server.transfer("simmulation.asp")
case 3
server.transfer("update.asp")
end select
[/case]

Inside these pages, you can then access the form-values just like in the first page.
With response.redirect, you need to do some looping to read the querystring and append it to the querystring for the page you want to redirect to.

This is maybe a stupid example, but we all sometimes run into situation where we need to post some data to a page, but don't actually process it on that page.

Specially when you allow other sites to post formdata (or set up links with data in the querystring) to your app.
The page they need to post to, can then be a page that does some securitychecks an checks if the values are valid, where they come from (based on the referer or some key-value in the querystring) and then sends the data to a page that actually processes it.
Mostly, when you are working with this sort of 'listener'-like services, you don't actually process the data in the page that is called from outside.
And if you can't just transfer them with all the data, then it can get complicated to drag the data along.

Another settup is when you use a sort of messenger-based communication.
Suppose you have a shoppingcart application. If someone orders an item, this influences multiple systems : the accountency-department, shipping-department, stock-control-department.
Suppose that the application is modulised, and each department has a fairly independend tool.
Then you could have something like
- user posts form
- form goes to shipping-module. The data that shipping needs (country,state,articleID and quantity) is grabbed from the querystring and processed
- transfer to stock-module. The data that stock-control needs (articleID and quantity) is grabbed from the querystring and processed
- transfer to accountency. The data that accountency needs (userID and price) is grabbed from the querystring and processed
- message is sent to user (can also be sent before the transfer so that the processing continues while the user reads or surfs or leaves the site)

once again raf, you not only help with code but you give really good concept examples... It's great. thanx a lot for the time you took to post that reply.:thumbsup:

You're welcome :thumbsup:

raf is the bomb. :)

isnt'it? when is the next "most helpfull user" nomination? He's gonna have my full support;)

Thanks guys :o

Glad i can help. :thumbsup: