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@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
