0

So I am junior programmer, and I just started working with .net webforms a little over six months ago. I have been studying SEO, and trying to optimize best practices with a senior level developer. I feel like 302s or in .net webforms response.redirect is misused alot. It could just be our team's logical flow of processing. However with how webforms handle state such as with Server.Transfer, controls, viewstate, and the page lifecycle I feel like this isn’t true. I sorta feel like we are forced in some ways for ease of programming to use Response.Redirect. We are looking for the best way to handle Response.Redirect and feel like we possibly misuse it. Maybe this only matters for public pages considering search engines will split page ranking between two pages if a Response.Redirect is used. Overall we want to have best practices, and establish the best principles for our team.

Scenario 1: Use event attached to a checkbox control, when user clicks a postback is performed. In event within code behind we build the querystring based on the checkbox selection, and do a Response.Redirect to the same page. On first time page, check querystrings, and show results.

  1. Seems to me as not being a temporary redirect. Content may change but overall the page at that URL will always be there. Its not even a new page. That checkbox will always go to that URL. Shouldn't this just be a get request. To me instead of just doing a Response.Redirect it would be best to just change the results based on selection. Creating a single reusable function for this logical flow.

Scenario 2. We have an admin page with a grid displaying rows of information related to particular entities. Each row has a button corresponding to a details page for editing the entity. When the user clicks a button within a row on the grid, a postback is performed, an encrypted token is built based on the row item selected. Response.Redirect is performed to go the details page with the token passed as a querystring parameter.

  1. Doesn't seem like a temporary redirect to me. Everytime you click that button it will go to that particular items details page. The only workaround I could come up with is to build each row items url with the token, on first time page load. Instead of doing a post, redirect, get, it will be just a get.

This is just two scenarios where we use Response.Redirect. We could probably show 10 to 15 common use cases that we use for Response.Redirect, and all of them seem misused in my opinion. Is this just the best way to do things in the webforms stack? How would a MVC application handle scenarios 1 and 2, would a redirect be preferred? I feel like each of our usecases needs to be examined, and determine best approach to avoid Response.Redirect. The lead developer of the project is looking for a single solution to handle all usecases for simplicity, less programming hours and without major architectural changes. I haven't been able to develop a solution that satisfies his requirements.

Note: added MVC tag because maybe one of the senior devs who has worked with both stacks (webforms and mvc) can answer the questions/concerns better.

Improve this question
1
  • Response.Redirect is indeed a common way of moving users from page to page in a web forms app, or to reload the page entirely. If its behind any kind of user account, SEO won't be a concern as well. Commented Mar 23, 2018 at 13:26

2 Answers 2

Reset to default
2

Post, redirect, get is a standard pattern used to avoid duplicate form submissions. It's a bit unclear to me why you consider this abuse. The redirect is temporary as a permanent redirect can be cached by indexers and you're telling them the url redirected from its going away and not to consider it again in the future. That doesn't sound like what you want in either scenario.

https://en.m.wikipedia.org/wiki/Post/Redirect/Get
https://stackoverflow.com/a/1393298/347348

Improve this answer
4
  • I understand that PRG is a common design pattern for form submission. In Web forms every page is one form, and having multiple forms on the same page can be a pain. So we tend to use Response.Redirect alot which is a http temporary move. Commented May 27, 2018 at 22:35
  • @grim Web forms is trying to simulate building web apps in the same way you'd build a desktop app which relies on event handlers and maintaining client state. If you asp.net server controls what you're seeingis just how it works. You need to remember it predates many current architectures. Of course you don't have to use any server controls but you can't use the builtin event handles. I'm not really sure what your objection is though. There's no rule you can't redirect to the page you're on, and 302 is appropriate. Commented May 28, 2018 at 22:46
  • Thanks, Yeah I guess its just the current framework which forces the use of 302 versus more modern frameworks which you tend to use 302's very less often. 302's are bad for SEO, and they are much slower. Seems like web form applications in general tend to use the PRG pattern alot more. Commented May 29, 2018 at 15:04
  • @Grim I think you're overly worried about 302s; especially after a form post, since search engines don't post to forms anyway, so what happens after a post is irrelevant. I'm not sure what you're comparison for speed is either. Server.Transfer has its own issues/limitations as well. Even if you were doing MVC, best practices would still have you do post/redirect/get. Commented May 29, 2018 at 22:50
0

I follow your opinion; in both scenarios a redirect is not justified.

This is mainly bad for performance; each such action hits the webserver twice and the full lifecycle of the webpage involved gets executed twice. This also applies to the secundary dependencies like authentication, authorisation, etc.

I agree that a team must apply some kind of common way to do things, but this must be based on overall best practices and not on a one rule fits all approach.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.