Make HttpStatus.resolve return non-deprecated one #35659
+7
−7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Reorder
HttpStatus.CONTENT_TOO_LARGE
to appear before its deprecated counterpartPAYLOAD_TOO_LARGE
to align with existing ordering conventions.Details
In previous versions,
HttpStatus.resolve
(orvalueOf
) always returned non-deprecated HTTP status for given code. This was ensured implicitly, by placing non-deprecated enum entries before their respective deprecations. This was not ensured for413 Content Too Large
.You can see this lower in this enum -
422 Unprocessable Content
is before its deprecated422 Unprocessable Entity
and in previous versions,414 URI Too Long
was before its deprecated414 Request-URI Too Long
.Even JavaDoc (from
6.2.x
) for414
used to explitly state, that non-deprecated one will be returned:Therefore I believe that
CONTENT_TOO_LARGE
enum entry should be moved beforePAYLOAD_TOO_LARGE
to match that.