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 [email protected] _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
