Thoughts on response.redirect? Anyone have 0 problems? Or, anyone have problems?
-
Hey all, got one of those "real world" questions for everyone! I've got a classic ASP application that uses multiple .asp pages, each with a form. The user fills out 5 pages of forms, each one linking to another, using the old <form action=post action="nextform.asp"> setup. Example- user fills out their login information, and clicks next. Then, user fills out their preferred shipping information, and clicks next. Etc, etc. Now with .NET and code-behind, I have two options for moving the user to the next page. One is response.redirect, the other is server.transfer. They'll click the submit button, which will do a postback to the original form. Then, my code-behind saves the info into the session object, and will either redirect or transfer the client to the next form page. I target a "global" audience with my application, so I'm a bit concerned about the compatability of all this, as follows: Response.redirect: The W3C (World wide web consortium), for the HTTP protocal version 1.1, leads me to think that I (and therefore, all of us) are abusing the redirect command (302). It seems that the 302/redirect command is only for sending a user to a URL that's moved. It also seems to say that some browsers will misinterpret this as a GET, instead of a POST command. See the document here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 Besides the temporary relocation part, I'm concerned where it says that "the user agent (browser) must not automatically redirect the request unless confirmed by the user". Server.Transfer: This seemed like the answer, but it might not return valid HTML (multiple <body> tags)- and that might fail against my "global" target audience. That just about throws server.transfer out of the window for me; and leaves me with only one solution- response.redirect! Another solution is to possibly make one large page, with all the forms on it, and only making one visible at a time. But I see this as a particularly messy bit of code that would quickly become more trouble than it's worth. I analyzed the IIS logs of my application, and found out that 95% of my users were using at least IE 5.0. So this might "help" me, in that I can assume that response.redirect's will function as expected. So what I'd really appreciate from you guys is your thoughts on this! Have you deployed apps that work perfectly, using response.redirects? Or have you had probl
-
Hey all, got one of those "real world" questions for everyone! I've got a classic ASP application that uses multiple .asp pages, each with a form. The user fills out 5 pages of forms, each one linking to another, using the old <form action=post action="nextform.asp"> setup. Example- user fills out their login information, and clicks next. Then, user fills out their preferred shipping information, and clicks next. Etc, etc. Now with .NET and code-behind, I have two options for moving the user to the next page. One is response.redirect, the other is server.transfer. They'll click the submit button, which will do a postback to the original form. Then, my code-behind saves the info into the session object, and will either redirect or transfer the client to the next form page. I target a "global" audience with my application, so I'm a bit concerned about the compatability of all this, as follows: Response.redirect: The W3C (World wide web consortium), for the HTTP protocal version 1.1, leads me to think that I (and therefore, all of us) are abusing the redirect command (302). It seems that the 302/redirect command is only for sending a user to a URL that's moved. It also seems to say that some browsers will misinterpret this as a GET, instead of a POST command. See the document here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 Besides the temporary relocation part, I'm concerned where it says that "the user agent (browser) must not automatically redirect the request unless confirmed by the user". Server.Transfer: This seemed like the answer, but it might not return valid HTML (multiple <body> tags)- and that might fail against my "global" target audience. That just about throws server.transfer out of the window for me; and leaves me with only one solution- response.redirect! Another solution is to possibly make one large page, with all the forms on it, and only making one visible at a time. But I see this as a particularly messy bit of code that would quickly become more trouble than it's worth. I analyzed the IIS logs of my application, and found out that 95% of my users were using at least IE 5.0. So this might "help" me, in that I can assume that response.redirect's will function as expected. So what I'd really appreciate from you guys is your thoughts on this! Have you deployed apps that work perfectly, using response.redirects? Or have you had probl