Hi,
On 14-04-2024 03:00, Maxim Dounin wrote:
Thanks for the patch.
Note that 413 was "Payload Too Large" since RFC 7231, which was
then changed into "Content Too Large" in RFC 9110. Both reason
phrases, unfortunately, look worse than "Request Entity Too Large"
as introduced in RFC 2068, as they require additional information
to understand if the request or the response content is the source
of the problem.
And 414 was "Request-URI Too Long" since introduction in RFC 2068,
and changed to "URI Too Long" in RFC 7231 (and not changed in RFC
9110). That is, "Too Large" part is not consistent with any RFCs,
it should be "Too Long". The NGX_HTTP_REQUEST_URI_TOO_LARGE name
dates back to 12:055ed05235ae (nginx-0.0.1-2002-09-13-18:47:42
import), and likely was borrowed from Apache, which also uses
similar name (HTTP_REQUEST_URI_TOO_LARGE, see
https://svn.apache.org/repos/asf/httpd/httpd/trunk/include/httpd.h).
Overall, I tend to think that it would be wrong to change defines,
even if providing compatibility shims. OTOH, we can consider
updating text representations, similarly to how it is already the
case for 302 (which is NGX_HTTP_MOVED_TEMPORARILY, but "302
Found"). (But I would rather refrain from changing 413 due to
the above reason.)
Thanks for the status code archeology. I was already wondering about the
differences between the RFCs and nginx descriptions.
I've created a new patch where only the content generated by NGINX is
modified, and not the defines.
--
Michiel
--
nginx-devel mailing list
nginx-devel@freenginx.org
https://freenginx.org/mailman/listinfo/nginx-devel
