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

[António P. P. Almeida]

Nginx has actually no support for the 429 code. Either you fix it by
proposing a patch to support the error page in core or you use an
error_page directive.

    error_page 429 @toomany;

     location @toomany {
         return 429 'Too many requests.\n';
     }

Just a simple example.
Le 28 oct. 2013 00:25, "Brian08275660" <nginx-forum at nginx.us> a écrit :

> Hi Francis,
>
> Probably I shouldn't have said "malformed" when I chose a word to express
> the problem with the response. But I assumed that Nginx should show the
> phrase that corresponds to the code. I assumed that Nginx has been coded so
> it know that 429 means "Too Many Requests" and that we should receive that
> string instead of the generic -and not very useful- string
> "Nginx/<version>". I just expected Nginx to behave with http status 429 as
> it does with http status 503.
> I agree that the client should know what to do. In fact, the most important
> thing is the code, and that is being delivered perfectly. I just think the
> explanation would be useful.
>
> I don't know why your output is different than mine. Weird!
>
> I know that I chose to send 429 to the client, yes, but given that 429
> means
> "too many requests" for the whole world (I mean, its not a status that I
> haven just invented), wouldn't it be nice if Nginx considers this and
> delivers the correct phrase?
>
> Brian
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,244156,244181#msg-244181
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20131028/1e3ae8ad/attachment.html>