in search of the complete 444

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

in search of the complete 444

Jeffrey 'jf' Lim
I've been trying and scratching my head over this for some time now.
I've always set up a default server to return 444, but I've not been
able to make it do the 444 *always*. If I get an invalid response,
nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
444, and not return 400.

I've searched and tried various things (like setting "error_page 400"
to some location, and then returning 444 for that location), but I
have not found anything that really works. Is there just no way to
have a "complete" 444 response? What will it take to do this?

thanks,
-jf

--
He who settles on the idea of the intelligent man as a static entity
only shows himself to be a fool.
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: in search of the complete 444

Moshe Katz-2
I found the same question asked on StackOverflow a few years ago:  https://stackoverflow.com/questions/41421111/http-444-no-response-instead-of-404-403-error-pages 

The accepted answer says to do it this way:

```
error_page 400 =444 @blackhole;

location @blackhole {
    return 444;
}
```

They key that you missed is the "=444" in the error_page directive. It seems like you need BOTH that and the `return 444` in the location block.

Moshe



On Mon, Jun 8, 2020 at 4:35 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
I've been trying and scratching my head over this for some time now.
I've always set up a default server to return 444, but I've not been
able to make it do the 444 *always*. If I get an invalid response,
nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
444, and not return 400.

I've searched and tried various things (like setting "error_page 400"
to some location, and then returning 444 for that location), but I
have not found anything that really works. Is there just no way to
have a "complete" 444 response? What will it take to do this?

thanks,
-jf

--
He who settles on the idea of the intelligent man as a static entity
only shows himself to be a fool.
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: in search of the complete 444

Jeffrey 'jf' Lim
Thanks, Moshe. I've tried that, but I've found that if you send
anything that's invalid at the HTTP layer by nginx, like talking http
to a https server, or sending invalid http (random junk), you'll get
either 400 or 500. It's still not "complete", unfortunately.

-jf

--
He who settles on the idea of the intelligent man as a static entity
only shows himself to be a fool.

On Tue, Jun 9, 2020 at 4:54 AM Moshe Katz <[hidden email]> wrote:

>
> I found the same question asked on StackOverflow a few years ago:  https://stackoverflow.com/questions/41421111/http-444-no-response-instead-of-404-403-error-pages
>
> The accepted answer says to do it this way:
>
> ```
> error_page 400 =444 @blackhole;
>
> location @blackhole {
>     return 444;
> }
> ```
>
> They key that you missed is the "=444" in the error_page directive. It seems like you need BOTH that and the `return 444` in the location block.
>
> Moshe
>
>
>
> On Mon, Jun 8, 2020 at 4:35 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>>
>> I've been trying and scratching my head over this for some time now.
>> I've always set up a default server to return 444, but I've not been
>> able to make it do the 444 *always*. If I get an invalid response,
>> nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
>> 444, and not return 400.
>>
>> I've searched and tried various things (like setting "error_page 400"
>> to some location, and then returning 444 for that location), but I
>> have not found anything that really works. Is there just no way to
>> have a "complete" 444 response? What will it take to do this?
>>
>> thanks,
>> -jf
>>
>> --
>> He who settles on the idea of the intelligent man as a static entity
>> only shows himself to be a fool.
>> _______________________________________________
>> nginx mailing list
>> [hidden email]
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: in search of the complete 444

Moshe Katz
Sorry, I wasn't actually in front of a server where I could check it before I sent that.

I just spent some time playing around with it on one of my servers, and I found that the second answer there does seem to work:

```
location / {
    return 444;
}

error_page 400 500 =444 /444.html;

location = /444.html {
    return 444;
}

```

I tested this using curl (using "curl -k <a href="https://example.com/%" target="_blank">https://example.com/%" as my bad request to trigger the 400) and it seems to work as desired in HTTP 1.0 and 1.1. However, when using HTTP2, curl just hangs instead of showing an error that the connection is closed. If your site doesn't respond to HTTP2 (which is fine since it's a do-nothing site anyway), then you don't have to worry about it.

Moshe



On Mon, Jun 8, 2020 at 8:40 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
Thanks, Moshe. I've tried that, but I've found that if you send
anything that's invalid at the HTTP layer by nginx, like talking http
to a https server, or sending invalid http (random junk), you'll get
either 400 or 500. It's still not "complete", unfortunately.

-jf

--
He who settles on the idea of the intelligent man as a static entity
only shows himself to be a fool.

On Tue, Jun 9, 2020 at 4:54 AM Moshe Katz <[hidden email]> wrote:
>
> I found the same question asked on StackOverflow a few years ago:  https://stackoverflow.com/questions/41421111/http-444-no-response-instead-of-404-403-error-pages
>
> The accepted answer says to do it this way:
>
> ```
> error_page 400 =444 @blackhole;
>
> location @blackhole {
>     return 444;
> }
> ```
>
> They key that you missed is the "=444" in the error_page directive. It seems like you need BOTH that and the `return 444` in the location block.
>
> Moshe
>
>
>
> On Mon, Jun 8, 2020 at 4:35 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>>
>> I've been trying and scratching my head over this for some time now.
>> I've always set up a default server to return 444, but I've not been
>> able to make it do the 444 *always*. If I get an invalid response,
>> nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
>> 444, and not return 400.
>>
>> I've searched and tried various things (like setting "error_page 400"
>> to some location, and then returning 444 for that location), but I
>> have not found anything that really works. Is there just no way to
>> have a "complete" 444 response? What will it take to do this?
>>
>> thanks,
>> -jf
>>
>> --
>> He who settles on the idea of the intelligent man as a static entity
>> only shows himself to be a fool.
>> _______________________________________________
>> nginx mailing list
>> [hidden email]
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: in search of the complete 444

Jeffrey 'jf' Lim
No problem, Moshe! Thank you so much for testing this out for me! This
does take care of the case of "not HTTP" being sent (which is what
'curl -k <a href="https://localhost/%'">https://localhost/%' used to give me)... BUT, unfortunately I
still get a 400 with 'curl <a href="http://localhost:443'">http://localhost:443'. I believe you should
get the same if you were to send http to the https server?

-jf

On Tue, Jun 9, 2020 at 9:15 AM Moshe Katz <[hidden email]> wrote:

>
> Sorry, I wasn't actually in front of a server where I could check it before I sent that.
>
> I just spent some time playing around with it on one of my servers, and I found that the second answer there does seem to work:
>
> ```
> location / {
>     return 444;
> }
>
> error_page 400 500 =444 /444.html;
>
> location = /444.html {
>     return 444;
> }
> ```
>
> I tested this using curl (using "curl -k <a href="https://example.com/%">https://example.com/%" as my bad request to trigger the 400) and it seems to work as desired in HTTP 1.0 and 1.1. However, when using HTTP2, curl just hangs instead of showing an error that the connection is closed. If your site doesn't respond to HTTP2 (which is fine since it's a do-nothing site anyway), then you don't have to worry about it.
>
> Moshe
>
>
>
> On Mon, Jun 8, 2020 at 8:40 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>>
>> Thanks, Moshe. I've tried that, but I've found that if you send
>> anything that's invalid at the HTTP layer by nginx, like talking http
>> to a https server, or sending invalid http (random junk), you'll get
>> either 400 or 500. It's still not "complete", unfortunately.
>>
>> -jf
>>
>> --
>> He who settles on the idea of the intelligent man as a static entity
>> only shows himself to be a fool.
>>
>> On Tue, Jun 9, 2020 at 4:54 AM Moshe Katz <[hidden email]> wrote:
>> >
>> > I found the same question asked on StackOverflow a few years ago:  https://stackoverflow.com/questions/41421111/http-444-no-response-instead-of-404-403-error-pages
>> >
>> > The accepted answer says to do it this way:
>> >
>> > ```
>> > error_page 400 =444 @blackhole;
>> >
>> > location @blackhole {
>> >     return 444;
>> > }
>> > ```
>> >
>> > They key that you missed is the "=444" in the error_page directive. It seems like you need BOTH that and the `return 444` in the location block.
>> >
>> > Moshe
>> >
>> >
>> >
>> > On Mon, Jun 8, 2020 at 4:35 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>> >>
>> >> I've been trying and scratching my head over this for some time now.
>> >> I've always set up a default server to return 444, but I've not been
>> >> able to make it do the 444 *always*. If I get an invalid response,
>> >> nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
>> >> 444, and not return 400.
>> >>
>> >> I've searched and tried various things (like setting "error_page 400"
>> >> to some location, and then returning 444 for that location), but I
>> >> have not found anything that really works. Is there just no way to
>> >> have a "complete" 444 response? What will it take to do this?
>> >>
>> >> thanks,
>> >> -jf
>> >>
>> >> --
>> >> He who settles on the idea of the intelligent man as a static entity
>> >> only shows himself to be a fool.
>> >> _______________________________________________
>> >> nginx mailing list
>> >> [hidden email]
>> >> http://mailman.nginx.org/mailman/listinfo/nginx
>> >
>> > _______________________________________________
>> > nginx mailing list
>> > [hidden email]
>> > http://mailman.nginx.org/mailman/listinfo/nginx
>> _______________________________________________
>> nginx mailing list
>> [hidden email]
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: in search of the complete 444

Moshe Katz-2
Have you tried adding response code 497 to your `error_pages` list?

I can't test now because I'm away from my nginx machines again at the moment, but the documentation for that case is here: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors

Moshe



On Mon, Jun 8, 2020 at 9:30 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
No problem, Moshe! Thank you so much for testing this out for me! This
does take care of the case of "not HTTP" being sent (which is what
'curl -k <a href="https://localhost/%" rel="noreferrer" target="_blank">https://localhost/%' used to give me)... BUT, unfortunately I
still get a 400 with 'curl http://localhost:443'. I believe you should
get the same if you were to send http to the https server?

-jf

On Tue, Jun 9, 2020 at 9:15 AM Moshe Katz <[hidden email]> wrote:
>
> Sorry, I wasn't actually in front of a server where I could check it before I sent that.
>
> I just spent some time playing around with it on one of my servers, and I found that the second answer there does seem to work:
>
> ```
> location / {
>     return 444;
> }
>
> error_page 400 500 =444 /444.html;
>
> location = /444.html {
>     return 444;
> }
> ```
>
> I tested this using curl (using "curl -k <a href="https://example.com/%" rel="noreferrer" target="_blank">https://example.com/%" as my bad request to trigger the 400) and it seems to work as desired in HTTP 1.0 and 1.1. However, when using HTTP2, curl just hangs instead of showing an error that the connection is closed. If your site doesn't respond to HTTP2 (which is fine since it's a do-nothing site anyway), then you don't have to worry about it.
>
> Moshe
>
>
>
> On Mon, Jun 8, 2020 at 8:40 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>>
>> Thanks, Moshe. I've tried that, but I've found that if you send
>> anything that's invalid at the HTTP layer by nginx, like talking http
>> to a https server, or sending invalid http (random junk), you'll get
>> either 400 or 500. It's still not "complete", unfortunately.
>>
>> -jf
>>
>> --
>> He who settles on the idea of the intelligent man as a static entity
>> only shows himself to be a fool.
>>
>> On Tue, Jun 9, 2020 at 4:54 AM Moshe Katz <[hidden email]> wrote:
>> >
>> > I found the same question asked on StackOverflow a few years ago:  https://stackoverflow.com/questions/41421111/http-444-no-response-instead-of-404-403-error-pages
>> >
>> > The accepted answer says to do it this way:
>> >
>> > ```
>> > error_page 400 =444 @blackhole;
>> >
>> > location @blackhole {
>> >     return 444;
>> > }
>> > ```
>> >
>> > They key that you missed is the "=444" in the error_page directive. It seems like you need BOTH that and the `return 444` in the location block.
>> >
>> > Moshe
>> >
>> >
>> >
>> > On Mon, Jun 8, 2020 at 4:35 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>> >>
>> >> I've been trying and scratching my head over this for some time now.
>> >> I've always set up a default server to return 444, but I've not been
>> >> able to make it do the 444 *always*. If I get an invalid response,
>> >> nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
>> >> 444, and not return 400.
>> >>
>> >> I've searched and tried various things (like setting "error_page 400"
>> >> to some location, and then returning 444 for that location), but I
>> >> have not found anything that really works. Is there just no way to
>> >> have a "complete" 444 response? What will it take to do this?
>> >>
>> >> thanks,
>> >> -jf
>> >>
>> >> --
>> >> He who settles on the idea of the intelligent man as a static entity
>> >> only shows himself to be a fool.
>> >> _______________________________________________
>> >> nginx mailing list
>> >> [hidden email]
>> >> http://mailman.nginx.org/mailman/listinfo/nginx
>> >
>> > _______________________________________________
>> > nginx mailing list
>> > [hidden email]
>> > http://mailman.nginx.org/mailman/listinfo/nginx
>> _______________________________________________
>> nginx mailing list
>> [hidden email]
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: in search of the complete 444

Jeffrey 'jf' Lim
Wow, Moshe. Thank you; I've honestly never seen this. This is great!
It looks like my 444 might actually be "complete" :) I'll give it some
time to see if I get any more traffic that escapes the 444, but this
might really be it...

thanks!
-jf

On Tue, Jun 9, 2020 at 9:51 AM Moshe Katz <[hidden email]> wrote:

>
> Have you tried adding response code 497 to your `error_pages` list?
>
> I can't test now because I'm away from my nginx machines again at the moment, but the documentation for that case is here: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors
>
> Moshe
>
>
>
> On Mon, Jun 8, 2020 at 9:30 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>>
>> No problem, Moshe! Thank you so much for testing this out for me! This
>> does take care of the case of "not HTTP" being sent (which is what
>> 'curl -k <a href="https://localhost/%'">https://localhost/%' used to give me)... BUT, unfortunately I
>> still get a 400 with 'curl <a href="http://localhost:443'">http://localhost:443'. I believe you should
>> get the same if you were to send http to the https server?
>>
>> -jf
>>
>> On Tue, Jun 9, 2020 at 9:15 AM Moshe Katz <[hidden email]> wrote:
>> >
>> > Sorry, I wasn't actually in front of a server where I could check it before I sent that.
>> >
>> > I just spent some time playing around with it on one of my servers, and I found that the second answer there does seem to work:
>> >
>> > ```
>> > location / {
>> >     return 444;
>> > }
>> >
>> > error_page 400 500 =444 /444.html;
>> >
>> > location = /444.html {
>> >     return 444;
>> > }
>> > ```
>> >
>> > I tested this using curl (using "curl -k <a href="https://example.com/%">https://example.com/%" as my bad request to trigger the 400) and it seems to work as desired in HTTP 1.0 and 1.1. However, when using HTTP2, curl just hangs instead of showing an error that the connection is closed. If your site doesn't respond to HTTP2 (which is fine since it's a do-nothing site anyway), then you don't have to worry about it.
>> >
>> > Moshe
>> >
>> >
>> >
>> > On Mon, Jun 8, 2020 at 8:40 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>> >>
>> >> Thanks, Moshe. I've tried that, but I've found that if you send
>> >> anything that's invalid at the HTTP layer by nginx, like talking http
>> >> to a https server, or sending invalid http (random junk), you'll get
>> >> either 400 or 500. It's still not "complete", unfortunately.
>> >>
>> >> -jf
>> >>
>> >> --
>> >> He who settles on the idea of the intelligent man as a static entity
>> >> only shows himself to be a fool.
>> >>
>> >> On Tue, Jun 9, 2020 at 4:54 AM Moshe Katz <[hidden email]> wrote:
>> >> >
>> >> > I found the same question asked on StackOverflow a few years ago:  https://stackoverflow.com/questions/41421111/http-444-no-response-instead-of-404-403-error-pages
>> >> >
>> >> > The accepted answer says to do it this way:
>> >> >
>> >> > ```
>> >> > error_page 400 =444 @blackhole;
>> >> >
>> >> > location @blackhole {
>> >> >     return 444;
>> >> > }
>> >> > ```
>> >> >
>> >> > They key that you missed is the "=444" in the error_page directive. It seems like you need BOTH that and the `return 444` in the location block.
>> >> >
>> >> > Moshe
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Jun 8, 2020 at 4:35 PM Jeffrey 'jf' Lim <[hidden email]> wrote:
>> >> >>
>> >> >> I've been trying and scratching my head over this for some time now.
>> >> >> I've always set up a default server to return 444, but I've not been
>> >> >> able to make it do the 444 *always*. If I get an invalid response,
>> >> >> nginx "skips" the 444 to return 400 instead. I'd rather nginx do the
>> >> >> 444, and not return 400.
>> >> >>
>> >> >> I've searched and tried various things (like setting "error_page 400"
>> >> >> to some location, and then returning 444 for that location), but I
>> >> >> have not found anything that really works. Is there just no way to
>> >> >> have a "complete" 444 response? What will it take to do this?
>> >> >>
>> >> >> thanks,
>> >> >> -jf
>> >> >>
>> >> >> --
>> >> >> He who settles on the idea of the intelligent man as a static entity
>> >> >> only shows himself to be a fool.
>> >> >> _______________________________________________
>> >> >> nginx mailing list
>> >> >> [hidden email]
>> >> >> http://mailman.nginx.org/mailman/listinfo/nginx
>> >> >
>> >> > _______________________________________________
>> >> > nginx mailing list
>> >> > [hidden email]
>> >> > http://mailman.nginx.org/mailman/listinfo/nginx
>> >> _______________________________________________
>> >> nginx mailing list
>> >> [hidden email]
>> >> http://mailman.nginx.org/mailman/listinfo/nginx
>> >
>> > _______________________________________________
>> > nginx mailing list
>> > [hidden email]
>> > http://mailman.nginx.org/mailman/listinfo/nginx
>> _______________________________________________
>> nginx mailing list
>> [hidden email]
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> [hidden email]
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx