HttpLimitReqModule delivers "nginx/1.4.3" as a message for HTTP status code 429. Too generic!

[Francis Daly]

On Sun, Oct 27, 2013 at 09:40:11AM -0400, Brian08275660 wrote:

Hi there,

> I think I'm actually reporting a malformed response, it is Nginx that send
> "nginx/1.4.3" instead of something useful as "too many requests".

This is quite confusing to me.

What you have shown looks well-formed to me, but doesn't look as useful
as you want. (They are different things. If it is a well-formed http
429 response, then it is the client's job to know what that means. The
reason-phrase and the http body content are optional enhancements that
the server can choose to send. According to my reading of RFC 2616.)

What is confusing is that when I do something similar, I get different
output which does not look well-formed to me:

===
$ curl -i -s http://localhost:8000/a.html | od -bc | head -n 6
0000000 110 124 124 120 057 061 056 061 040 064 062 071 015 012 123 145
          H   T   T   P   /   1   .   1       4   2   9  \r  \n   S   e
0000020 162 166 145 162 072 040 156 147 151 156 170 057 061 056 064 056
          r   v   e   r   :       n   g   i   n   x   /   1   .   4   .
0000040 063 015 012 104 141 164 145 072 040 123 165 156 054 040 062 067
          3  \r  \n   D   a   t   e   :       S   u   n   ,       2   7
===

The lack of a space immediately following "429" up there looks incorrect
to me.

This is when using:

===
$ sbin/nginx -V
nginx version: nginx/1.4.3
built by gcc 4.4.5 (Debian 4.4.5-8) 
configure arguments: --with-debug

$ cat conf/nginx.conf

events {
    worker_connections  1024;
    debug_connection 127.0.0.1;
}

http {
    limit_req_zone $binary_remote_addr zone=zone1:128m rate=1r/m;

    limit_req_status 429;
    server {
        location = /a.html {
            limit_req zone=zone1 nodelay;
        }
    }
}
===

> I have
> tested it with Firefox and there is no doubt. Also tested it with a java
> HTTP client component, the same result. The status code received is correct
> (429), but not the message that comes with it.

The message is irrelevant from a correctness point of view.

> I had just discovered the "error_page" directive after I sent the email, I
> will create it, thanks. It is easy to do it. But why doesn't nginx deliver a
> default HTML response for 429, as it does for 503 and other codes?

My guess is that nginx doesn't claim to support whichever standard
defines code 429; so as far as nginx is concerned, you using it is just
like you using, say, code 477. It's a number you choose, so you get to
ensure that the client can handle it.

(It seems to be RFC 6585, currently "Proposed Standard", that defines 429.)

Now I think that it would probably be nice if there were a way to
provide a reason-phrase alongside a status code in nginx. I'm sure that
if somebody cares enough, a patch will be forthcoming.

And if we can find out why the response that you get and the response
that I get differ, and if it turns out that the one that is generated
by pure-nginx is actually malformed and causes a client that matters to
break, then that may become patched too.

But the response you get looks correct to me, for a status code that nginx
doesn't know about. The client knows it is a client error (400-series);
if the client supports RFC 6585 is also knows that it means "Too Many
Requests"; and if it doesn't, it can show the body that you choose to
send with error_page so that the user can work out what it means.

	f
-- 
Francis Daly        francis at daoine.org