[PATCH] HTTP: added the preserve_method option to the error_page directive.
Maxim Dounin
mdounin at mdounin.ru
Wed Sep 4 12:01:55 UTC 2019
Hello!
On Tue, Sep 03, 2019 at 12:07:53PM -0700, Thibault Charbonnier wrote:
> # HG changeset patch
> # User Thibault Charbonnier <thibaultcha at me.com>
> # Date 1567537546 25200
> # Tue Sep 03 12:05:46 2019 -0700
> # Node ID 68ba3d36bff4213e3fedc538021e8cbece85e508
> # Parent 52b5ee64fe11ec267a0767cbb9874c8cae652299
> HTTP: added the preserve_method option to the error_page directive.
>
> As of today, the `error_page` directive will override the request method
> if redirecting to a non-named location and if said method is not `HEAD`.
>
> As for using named location (which preserve the request method), some
> error cases won't be able to perform the redirect (e.g. HTTP 414).
>
> This patch allows users who wish to set a single "catch-all" error
> location block to preserve the client method for logging purposes.
>
> A new option `preserve_method` is added to the directive:
>
> error_page 400 preserve_method /error_handler;
No, thank you. This seems to complicate things for no real
reason. For logging purposes consider using $request variable,
which constains original request line, including request method,
as long as it is available.
Note well that it is generally a bad idea to redirect 400 errors.
While it may work in some cases, error 400 indicate a serious
error with the request, and it might not be possible to properly
handle such requests in a normal request processing pipeline due
to lack of various request fields normally available.
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx-devel
mailing list