Force GET Redirect on PUT and POST on HTTP Status Code 300-303

[mnaumanali94]

Currently, GET request is just forced for POST requests with a 300-303 response. This behavior should also be in place for PUT and DELETE considering they are not safe functions either. RestSharp does it like that.

If not, I couldn't even figure out a way to keep the current behavior and just handling it differently for these methods. From the looks of it, I'll have to implement the complete redirection logic to achieve the desired behavior.

[stephentoub]

This behavior should also be in place for PUT and DELETE considering they are not safe functions either

Is there an HTTP-related specification somewhere that dictates that?

[davidsh]

We generally follow RFC 7231. Section 6.4 covers behaviors for redirection: https://tools.ietf.org/html/rfc7231.html#section-6.4

[davidsh]

Currently, GET request is just forced for POST requests with a 300-303 response.

RFC 7231 describes the behavior for POST redirects and indicates it should transform to GET.

This behavior should also be in place for PUT and DELETE considering they are not safe functions either. RestSharp does it like that.

However, there are no described behaviors in the RFC for transforming PUT or DELETE. If RestSharp is doing that, then it is inventing a new behavior.

What do browsers do in these cases?

[mnaumanali94]

Alright. You are right the RFC's are not clear. I tried tools like postman that did the mapping to GET even for PUT and DELETE. My understanding is that due to the confusion 307 and 308 were made to ensure request method are not rewritten. For 301 and 302 the behavior varies across tools. 303 maps to GET in most cases even for PUT and DELETE.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections#Temporary_redirections.

For 303 the rewriting should happen in my opinion. 301 and 302 are debatable.

[JoeEdwardsCode]

It should be noted that forcing a GET on 303 for a PUT is the behavior of System.Net.Http in .NET Framework from what I can tell.

[karelz]

Triage: We should match .NET Framework in cases where RFC is not clear.

[TimothyByrd]

Is this stackoverflow answer wrong?

303: Redirect for undefined reason. Typically, 'Operation has completed, continue elsewhere.'
Clients making subsequent requests for this resource should not use the new URI. Clients
should follow the redirect for POST/PUT/DELETE requests, but use GET for the follow-up request.

I just converted a utility from Net Framework to Net 5.0, and the results were not pretty.

I'm doing a PUT to https://www.example.com/thing/12345 and the server returns a 303 with the same URI in the Location header, as a way to say "if you want the new value of this expensive thing, come and GET it".

In Net Framework, the retry does a GET on https://www.example.com/thing/12345 and the server returns a 200 result and all is well.

In Net 5.0, the retry does another PUT to https://www.example.com/thing/12345 and the server returns 303 again.
This repeats for the default 50 retries, and then I finally get the 303 back to do something with.

I'm not clear on what use case this is desirable behaviour.

Since I didn't want to completely disable retries for my GETs, too, the smallest way to compensate seemed to be to set MaxAutomaticRedirections = 1 then manually handle the 303 for the PUT.

[geoffkizer]

Here's my take on the RFC language, taken from https://tools.ietf.org/html/rfc7231#section-6.4

300 Multiple Choices is a weird one and not really used in practice. The RFC is unclear here. I would suggest we not make any change here.

301 Moved Permanently and 302 Found both explicitly state:

For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

So I think our current behavior here (only change POST) is correct.

303 See Other explicitly states:

This status code is applicable to any HTTP method.

So, I think we should change the behavior for 303 to change the method to GET for all methods (not just PUT). I believe this matches both .NET Framework behavior and common practice.

@scalablecory @stephentoub Any concerns here?

[TimothyByrd]

Is there a place I can check the Net Framework code to make sure the behaviour is matching?
If there are places where the RFC is unclear, I suggest compatibility with the existing Net Framework.
Otherwise, I can't trust porting code that has worked for years.

[stephentoub]

@stephentoub Any concerns here?

If it brings us better in line with the spec and netfx, sounds good.