What problem are you trying to solve?

The documentation correctly states:

If a 303 is sent by the server in response to any request type (POST, DELETE, etc.), Got will request the resource pointed to in the location header via GET.
This is in accordance with the specification.

However, Section 6.4.3 of the same RFC also states:

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.

And indeed, I observe that even modern browsers like Chrome and/or Firefox do actually interpret a 302 in response to a POST Request as if it was a 303. I furthermore observe that there are still quite some servers around (including some I have to work with at my workplace) that do send 302 responses even though they should actually send 303 - be it because they need to handle legacy (i.e., pre-HTTP/1.1) clients which do not understand a 303 status code, or simply because they can count on the Browsers to do the right thing.

Describe the feature

For working with servers which do behave as described above (i.e., which send 302 responses when they actually should send a 303), it would be great to have an option which enables "legacy-handling" of 302 responses, i.e., which also changes the request method to GET and clears all request body contents when receiving a 302 response status code.

Currently, I always need to do a workaround like this:

got.post('http://foo.bar', {
    ...
    hooks: {
        beforeRedirect: [
            (options, response) => {
                if (response.statusCode === 302) {
                    options.method = 'GET'
                    options.json = undefined
                }
            }
        ]
    }
})

Checklist

• I have read the documentation and made sure this feature doesn't already exist.