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