in search of the complete 444

[Moshe Katz]

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 at 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 at 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 at 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 at 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 at 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 at nginx.org
> >> >> http://mailman.nginx.org/mailman/listinfo/nginx
> >> >
> >> > _______________________________________________
> >> > nginx mailing list
> >> > nginx at nginx.org
> >> > http://mailman.nginx.org/mailman/listinfo/nginx
> >> _______________________________________________
> >> nginx mailing list
> >> nginx at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx
> >
> > _______________________________________________
> > nginx mailing list
> > nginx at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200608/57e9396e/attachment-0001.htm>