Hi!


> 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:

I think nginx is returning the same thing for you both, and that curl
fails to parse this bogus HTTP response (maybe you are using different
curl releases).

If we look again at Brian's curl output, we don't see any Server header
in the response, which is not configurable in nginx afaik:

< HTTP/1.1 429 nginx/1.4.3  <--- THIS IS WRONG
< Date: Sun, 27 Oct 2013 17:12:42 GMT
< Content-Length: 0
< Connection: keep-alive



From rfc2616#section-6.1 [1]:

> 6.1 Status-Line
>
>  The first line of a Response message is the Status-Line, consisting
>  of the protocol version followed by a numeric status code and its
>  associated textual phrase, with each element separated by SP
>  characters. No CR or LF is allowed except in the final CRLF sequence.
>
>    Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

While nginx seems to return:
  HTTP-Version SP Status-Code CRLF

as per Francis' output.

The Reason-Phrase clearly is a hard requirement and cannot be omitted.



Regards,

Lukas


[1] http://tools.ietf.org/html/rfc2616#section-6.1
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx