This is a simple AspDotNet server with a couple client projects to check how browsers, the Net Framework HttpClient and the Net 5.0 HttpClient react when the response from the server is one of the redirect responses (300, 301, 302, 303, 307 or 308).
This started because I ported a networking client from Net Framework to Net 5.0 and it compiled without error, but it didn't work any more.
I then found an open issue in the dotnet/runtime project and put in effort to fix it.
Summary
How I got the data
Firefox
Chrome/Edge
Net Framework
Net 5.0
Donation
(Ignoring the current behavior of Net 5.0, since that's what I'm looking at changing.)
The only times a redirect seems to change method to a GET is:
- On a 303 response, except the HEAD will remain HEAD.
- POST also changes to GET on a 301 or 302.
- Net Framework also changes all except HEAD to GET on a 300.
- And I said I would ignore it, but Net 5.0 also changes POST to GET on a 300.
For each of the browsers, I opened the swagger page in that browser. I went through each of the HTTP methods and for each method tried the "initial" API once for each of the 30x result status codes. In the console window for the service, I could see what calls were made.
For example, if I do a POST to the /Redirect/initial/303 API in Firefox, I see the following in the serrvice console. This implies that Firefox followed the redirect and changed the method from POST to GET.
For Net Framework and Net, I ran the client programs which do the same thing (iterate over methods and 30x codes) and looked at what appeared in the console window for the service.
The swagger page:
| Meth/Stat | 300 | 301 | 302 | 303 | 307 | 308 |
|---|---|---|---|---|---|---|
| DELETE | DELETE | DELETE | DELETE | GET | DELETE | DELETE |
| GET | GET | GET | GET | GET | GET | GET |
| HEAD | HEAD * | HEAD * | HEAD | HEAD | HEAD | HEAD |
| OPTIONS | OPTIONS | OPTIONS | OPTIONS | GET | OPTIONS | OPTIONS |
| PATCH | PATCH | PATCH | PATCH | GET | PATCH | PATCH |
| POST | POST | GET | GET | GET | POST | POST |
| PUT | PUT | PUT | PUT | GET | PUT | PUT |
Firefox is unusual in that - for the HEAD method only - if the server returns a 300 or 301, after following to the redirect URI the first time, it never uses the initial URI again. If the initial URI is invoked again, Firefox ignores it and goes straight to the redirect URI.
| Meth/Stat | 300 | 301 | 302 | 303 | 307 | 308 |
|---|---|---|---|---|---|---|
| DELETE | error | DELETE | DELETE | GET | DELETE | DELETE |
| GET | error | GET | GET | GET | GET | GET |
| HEAD | error | HEAD | HEAD | HEAD | HEAD | HEAD |
| OPTIONS | error | OPTIONS | OPTIONS | GET | OPTIONS | OPTIONS |
| PATCH | error | PATCH | PATCH | GET | PATCH | PATCH |
| POST | error | GET | GET | GET | POST | POST |
| PUT | error | PUT | PUT | GET | PUT | PUT |
Chrome and Edge exhibit identical behavior. If the server returns a 300 response, they show an "Error: Multiple Choices" in the swagger page and do not follow the redirect.
| Meth/Stat | 300 | 301 | 302 | 303 | 307 | 308 |
|---|---|---|---|---|---|---|
| DELETE | GET | DELETE | DELETE | GET | DELETE | none |
| GET | GET | GET | GET | GET | GET | none |
| HEAD | HEAD | HEAD | HEAD | HEAD | HEAD | none |
| OPTIONS | GET | OPTIONS | OPTIONS | GET | OPTIONS | none |
| PATCH | GET | PATCH | PATCH | GET | PATCH | none |
| POST | GET | GET | GET | GET | POST | none |
| PUT | GET | PUT | PUT | GET | PUT | none |
Net Framework does not follow the redirect on a 308 response.
| Meth/Stat | 300 | 301 | 302 | 303 | 307 | 308 |
|---|---|---|---|---|---|---|
| DELETE | DELETE | DELETE | DELETE | DELETE | DELETE | DELETE |
| GET | GET | GET | GET | GET | GET | GET |
| HEAD | HEAD | HEAD | HEAD | HEAD | HEAD | HEAD |
| OPTIONS | OPTIONS | OPTIONS | OPTIONS | OPTIONS | OPTIONS | OPTIONS |
| PATCH | PATCH | PATCH | PATCH | PATCH | PATCH | PATCH |
| POST | GET | GET | GET | GET | POST | POST |
| PUT | PUT | PUT | PUT | PUT | PUT | PUT |
If this project helped you, you can help me :)
