HTTP 505 error message supported by NGINX?

Server NGINX
1

Hi, does NGINX support the generation of the error message for HTTP
error
code 505? For example, I see

“401 Authorization Required” when running nginx 1.6.2
but I don’t see anything for 505. NGINX would return “505 OK” in the
HTTP
response.

Thank you.

Posted at Nginx Forum:

2

There is no such HTTP 505 “OK”.
It means “HTTP Version Not Supported”.

What were you testing?
How did you test it?
What result did you expect?
What result did you get?

B. R.

3

I have my FCGI server send “HTTP/1.1 505 Version Not
Supported\r\nStatus:
505 Version Not Supported\r\n\r\n”.
In nginx.conf, I have:

      fastcgi_intercept_errors on;
      error_page 505 /errpage;
      location /errpage {
                 try_files /version_not_supported.html =505;
      }

If version_not_supported.html is not found, I expected nginx to display
“505
HTTP Version Not Supported” on the browser page, and to return “Status
Code:
505 HTTP Version Not Supported” in the HTTP response. Instead, I got a
blank
page, and the HTTP response shows a Status code of “505 OK”.

Note NGINX displays the correct error message and Status code for other
error codes such as 400, 401, 403, 404, 500, etc. Just for 505, NGINX
would
not return the proper error message.

Posted at Nginx Forum:

4

Thank you Francis. The body content did the trick … not as
aesthetically
pleasing to the eyes as the NGINX’s “hard-coded reason phrase”, but it
is
better than a blank page.
I did not understand what you meant by a config to control the reason
phrase.
Thanks again.

Posted at Nginx Forum:

5

On Tue, Aug 04, 2015 at 06:19:03PM -0400, nginxuser100 wrote:

Hi there,

If version_not_supported.html is not found, I expected nginx to display “505
HTTP Version Not Supported” on the browser page, and to return “Status Code:
505 HTTP Version Not Supported” in the HTTP response. Instead, I got a blank
page, and the HTTP response shows a Status code of “505 OK”.

I think that you can control the HTTP status code that nginx returns,
and you can control the body content returned with the response; but
you cannot control the “reason phrase” that nginx puts on the status
line.

So nginx can be told to return (for example) "HTTP/1.1 505 " with the
body content that you choose. If that is good enough for what you want,
you won’t need to go beyond nginx.conf to achieve it.

(To do that, you could replace “=505” with “@my505”, and then in
“location @my505” do “return 505 my_body_content”. I’m sure that other
ways of achieving the same thing exist too.)

What the browser chooses to do with the 505 response is its business –
perhaps it will show its own “505” page instead of what nginx sent;
or perhaps it will show exactly what nginx sent.

Note NGINX displays the correct error message and Status code for other
error codes such as 400, 401, 403, 404, 500, etc. Just for 505, NGINX would
not return the proper error message.

I think that nginx returns its hard-coded “reason phrase” for each of
those status codes. It happens not to have one for 505, so it returns
the empty one.

Or do you have a config when you can control the reason phrase for those
status codes?

Cheers,

f

Francis D. [email protected]

6

Thank you B.R. I wonder why 505 was not supported.

Posted at Nginx Forum:

7

It seems that by default nginx does not handle that HTTP code.

I just tried the following:
HEAD / HTTP/30.00
User-Agent: lollipop
Host: [EDITED]
Accept: /

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 04 Aug 2015 23:27:43 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Strict-Transport-Security: max-age=15984000

​So if you overload the status code with 505, the reason won’t change
and
still be ‘OK’.​
​That would explain why you saw ‘505 OK’ which is an heresy…​

B. R.

8

On Tue, Aug 04, 2015 at 07:25:23PM -0400, nginxuser100 wrote:

Hi there,

Thank you Francis. The body content did the trick … not as aesthetically
pleasing to the eyes as the NGINX’s “hard-coded reason phrase”, but it is
better than a blank page.

Good that you have an acceptable answer.

I did not understand what you meant by a config to control the reason
phrase.

I think that nginx does not have a way to let you control the reason
phrase.

I was not sure from your paragraph whether you had a system where
you got nginx to return a different reason phrase, for (e.g.) fastcgi
returning 404.

If you had, I’d be interested to see the config.

But it sounds like you don’t, so that’s ok.

Cheers,

f

Francis D. [email protected]