Created by: Jonas1893
The success range of a HTTP response which defines whether a response should be treated as successful or failed is currently hardcoded in the URLSession / AlamofireImplementations to 200..<300. There are use cases where users of the generator do not want the request to fail if a response code is outside this range, like e.g. when status code is in 3** range.
This PR solves problem 2. described in #13597 (closed) by adding a new parameter successfulStatusCodeRange to Configuration which is injected into response validations for Alamofire and URLSession libraries (not applicable for Vapor). If unchanged the behavior remains the same as before for both libraries
This change is the basis for an implementation of follow redirects in the generator which are currently silently performed but the response data is discarded. I would propose an implementation of follow redirects in a separate PR, this change here is independent of it and has benefits past the scope of just follow redirects, that's why I separated it.
PR checklist
-
Read the contribution guidelines. -
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community. -
Run the following to build the project and update samples: Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH. -
File the PR against the correct branch: master(6.1.0) (minor release - breaking changes with fallbacks),7.0.x(breaking changes without fallbacks) -
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. -> @4brunu
Declaration
The program was tested solely for our own use cases, which might differ from yours.