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 <mo...@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.wo...@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 <kohenk...@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.wo...@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 <mo...@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.wo...@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
