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
