Ensure maintaining support for .disableFollowRedirect()

We need to keep support for 3xx where the redirect is disabled. In our case 3xx response code is defined to have a different meaning in our specification. So we need continued support for disabling the redirect for 3xx response code.
We are using .disableFollowRedirect() and want to ensure there is no plans to deprecate this feature in the future.

In our case 3xx response code is defined to have a different meaning in our specification.

What do you mean exactly?
Please elaborate.

3XX has been determined to mean that data is available, process is complete. We do not redirect on 3XX and I have seen other specifications that behave similarly. I want to make certain that this functionality is not deprecated.

3XX has been determined to mean that data is available, process is complete.

It looks to me you’re violating the HTTP specification.

IMHO, you could have used 2XX status codes with extra information in HTTP headers or in the response body.

I have seen other specifications that behave similarly

Could you please share some pointers? If some widely known technologies do behave like this, you would have a fair point.

I want to make certain that this functionality is not deprecated.

First, deprecating would enforce proper usage. Over the years, we’ve seen many times people using disableFollowRedirect so that they could parse the Location header, instead of using the currentLocation and currentLocationRegex checks. Extra support work for us.

Then, we traditionally have a policy of abiding to the HTTP specifications and rejecting supporting home made hacks and specs violations. Better fix issues upstream than work around them downstream on our side and bear the costs.