RedirectResult support for 303 (See Other)

[Davilink]

Is your feature request related to a problem?

Hi, i was reading the RedirectResult class : https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.redirectresult?view=aspnetcore-2.2
and the HTTP Code "See Other (303)" is not mention here.

Describe the solution you'd like

Add the HTTP Code status in RedirectResult

[pranavkm]

Is there a specific scenario where it's useful to you? This is the first we've been asked about this status code and I'm trying to understand why you'd use 303 over 302 or 307.

[Davilink]

We have kind of a workaround for that redirect an http:// to a app:// scheme to by pass an email problem and the user agent has to do a GET on that app://scheme to work. The same endpoint is use by POST, PUT for a 2 part operation. The GET is an temporary redirection workaround that is associated with the POST, PUT operation.

The method and the body of the original request are reused to perform the redirected request. In the cases where you want the method used to be changed to GET, use 303 See Other instead. This is useful when you want to give an answer to a PUT method that is not the uploaded resources, but a confirmation message (like "You successfully uploaded XYZ").

The only difference between 307 and 302 is that 307 guarantees that the method and the body will not be changed when the redirected request is made. With 302, some old clients were incorrectly changing the method to GET: the behavior with non-GET methods and 302 is then unpredictable on the Web, whereas the behavior with 307 is predictable. For GET requests, their behavior is identical.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307

Maybe i should use a 307 instead of a 303, but it's seem like 302 should not be used anymore. So i was wondering if the 303 was only forgotten or if that was for a reason.

[rmja]

@pranavkm

A use case is for the Put-Redirect-Get pattern equivalent of the Post-Redirect-Get pattern.

302: A post request is followed by a GET to the location header
302: A put request is followed by PUT to the location header

303: A post request is followed by a GET to the location header
303: A put request is followed by GET to the location header

The last is of cause the desired in this case

see e.g. https://stackoverflow.com/a/33215393/963753

[pranavkm]

Thanks. I've marked it as an enhancement and we can consider taking this for the next release. Feel free to send us a PR.

[pranavkm]

@Tratcher can HttpResponse.Redirect use 303 by default: https://github.com/aspnet/AspNetCore/blob/master/src/Http/Http/src/Internal/DefaultHttpResponse.cs#L159? It sounds like they're almost interchangeable (assuming the client understands HTTP 1/1).

[SARAVANA1501]

A 302 redirect is a temporary redirect. It is not cacheable by default and should be re-requested every time (but you can override this with caching headers). The follow-up request should use the same method (POST, GET, CONNECT, PUT, DELETE, etc.) as the original request and for anything other than GET and HEAD requests, the client should prompt the user before making the request. This is the part that the clients got wrong and most of them change the method for the follow-up request to GET, regardless of the original method.

A 303 redirect is the same as a 302 except that the follow-up request is now explicitly changed to a GET request and no confirmation is required.

[Tratcher]

@Tratcher can HttpResponse.Redirect use 303 by default:

Breaking change. I don't recommend it, 303 is not used or supported as broadly as 302.

[mkArtakMSFT]

After reviewing this issue one more time we believe that using the StatusCodeResult with 303 argument is sufficient here. We're closing this issue as no more action is pending here.