[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