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 <moshe@ymkatz.net> 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 <jfs.world@gmail.com> 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 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 <kohenkatz@gmail.com> 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 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 <jfs.world@gmail.com> 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 <moshe@ymkatz.net> 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 <jfs.world@gmail.com> 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
>> >> >> nginx@nginx.org
>> >> >> http://mailman.nginx.org/mailman/listinfo/nginx
>> >> >
>> >> > _______________________________________________
>> >> > nginx mailing list
>> >> > nginx@nginx.org
>> >> > http://mailman.nginx.org/mailman/listinfo/nginx
>> >> _______________________________________________
>> >> nginx mailing list
>> >> nginx@nginx.org
>> >> http://mailman.nginx.org/mailman/listinfo/nginx
>> >
>> > _______________________________________________
>> > nginx mailing list
>> > nginx@nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
