Can response code be 444 in error_page

Hello.

I want to reject a connection when some errors (400, 403, …) occur, so
I
used error code 444 in error_page like this:

error_page 400 =444 @reject_conn;
location @reject_conn {
return 444;
}

When I tested it, the network connection was waiting continuously, not
closed (reseted).
I wonder if this situation is right.
I also searched internet and read a document, but I could not find a
answer.

Is this situation right? (or, does the code work, well?)

Thanks.

Posted at Nginx Forum:

Maxim D. Wrote:

error_page 400 =444 @reject_conn;


nginx mailing list
[email protected]
nginx Info Page

Thank you for the reply.

I translated and read the report. I understood the bug is related with
only
error_page 400.
If this is correct, my example may be inappropriate.

My question was whether the response code of error_page can be 444, or
not.
(In the document, only standard HTTP codes are described.)
For another example, I want to reject inappropriate accesses such as 497
error.

error_page 497 =444 @reject_conn;
location @reject_conn {
return 444;
}

I expected that the connection is reset when error 497 occurs, but it
was
waiting.

Thanks.

Posted at Nginx Forum:

Hello!

On Wed, Nov 05, 2014 at 04:32:15AM -0500, bluekyu wrote:

When I tested it, the network connection was waiting continuously, not
closed (reseted).
I wonder if this situation is right.
I also searched internet and read a document, but I could not find a
answer.

Is this situation right? (or, does the code work, well?)

That’s a known bug, and we even have a ticket for it (though it
was filed in Russian by the reporter):

http://trac.nginx.org/nginx/ticket/274


Maxim D.
http://nginx.org/

Hello!

On Wed, Nov 05, 2014 at 09:00:30AM -0500, bluekyu wrote:

[…]

location @reject_conn {
return 444;
}

I expected that the connection is reset when error 497 occurs, but it was
waiting.

As 497 is just a special case of 400 (and it is actually changed
to 400 during handling), I suspect it’s affected by the same bug.


Maxim D.
http://nginx.org/