Use direct status code to avoid deprecation warnings.#52252
Conversation
ff3dba3 to
18ff3f3
Compare
18ff3f3 to
d586b37
Compare
|
Is |
|
Yes, IIUC, that's a reasonable usage. I think in the future (e.g. think once Rack 3.0 is dropped), we will probably want to remove this code. |
|
It looks like this is no longer needed as emitting a warning no longer causes test failures. |
|
The warning was just suppressed here #52751, something should still happen. |
|
I agree. |
|
Will you reopen or do you consider this done for now? I would recreate it if you have no interest in it anymore. |
|
I am happy to re-open it if there is a path towards getting it merged or rejected (both okay). |
|
I'd say ask in the discord but I see you already did that🙃. Maybe bump in the discord and reopen? |
Using `unprocessable_entity` will emit a warning on Rack 3.2. There have been various PRs in the past for this: * rails#52252 * rails#52192 * rails#52087 * rails#52097 This to me seems like the least invasive change and is also how headers are currently handled.
Using `unprocessable_entity` will emit a warning on Rack 3.2. There have been various PRs in the past for this: * rails#52252 * rails#52192 * rails#52087 * rails#52097 This to me seems like the least invasive change and is also how headers are currently handled.
Using `unprocessable_entity` will emit a warning on Rack 3.2. There have been various PRs in the past for this: * rails#52252 * rails#52192 * rails#52087 * rails#52097 This to me seems like the least invasive change and is also how headers are currently handled.
Using `unprocessable_entity` will emit a warning on Rack 3.2. There have been various PRs in the past for this: * rails#52252 * rails#52192 * rails#52087 * rails#52097 This to me seems like the least invasive change and is also how headers are currently handled.
Using `unprocessable_entity` will emit a warning on Rack 3.2. There have been various PRs in the past for this: * rails#52252 * rails#52192 * rails#52087 * rails#52097 This to me seems like the least invasive change and is also how headers are currently handled.
Motivation / Background
The HTTP status code 422 was informally referred to as "unprocessable entity" by the WebDAV specifications. However, it was officially standardised as "unprocessable content" by the HTTP standards. Rack adopted this change in v3.1 and emits deprecation warnings in v3.2 (HEAD).
The current released versions of Rack work acceptably with Rails, however Rack HEAD emits warnings, causing test failures.
See rack/rack#2137 for more context. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422 for more details about the specifications.
Detail
Use "422" status code directly in
exception_wrapper.rbto avoid the deprecation warning. This change bypasses symbolic name lookup and thus the deprecation warning, by using the status code directly. We may prefer to change all the symbolic constants to integer values to avoid extra hash lookups. However, it's probably not a performance issue in practice.Handle both
unprocessible_entityandunprocessible_contentinActionDispatch::Responseand the test assertions helper. This ensures compatibility with both symbols going forward, until Rails decides to drop support.Alternatives
I considered the following alternatives:
If there is enough interest in doing it differently, I'd be willing to consider those options.
Checklist
Before submitting the PR make sure the following are checked:
[Fix #issue-number]