Hello!

On Wed, Apr 03, 2013 at 12:09:25PM +0800, Weibin Yao wrote:

> Hi,
>
> Today In our test box I noticed that nginx sent bad response with 203
> response. You can reproduce the problem with the return directive:
>
> location / {
> return 203;
> }
>
> And the response looks like:
>
> HTTP/1.1
> Server: nginx/1.3.14
> Date: Wed, 03 Apr 2013 03:54:38 GMT
> Content-Type: application/octet-stream
> Content-Length: 0
> Connection: keep-alive
>
> This is actually not an illegal HTTP/1.1 response.
>
> I noticed the related code in the ngx_http_header_filter_module.c:
>
> 53 static ngx_str_t ngx_http_status_lines[] = {
> 54
> 55 ngx_string("200 OK"),
> 56 ngx_string("201 Created"),
> 57 ngx_string("202 Accepted"),
> 58 ngx_null_string, /* "203 Non-Authoritative Information" */
> 59 ngx_string("204 No Content"),
> 60 ngx_null_string, /* "205 Reset Content" */
> 61 ngx_string("206 Partial Content"),
>
> It seems this behaviour is expected intentionally. It does not follow the
> RFC 2616. If we replace it to be the meaningful status code. Is there any
> problem?

It think this is a bug. The ngx_http_status_lines[] array doesn't
contain lines for status codes nginx doesn't generate itself, but
the code doesn't expect such a hole may be actually hit. On the
other hand, for unknown codes outside of the known range it
correctly returns just a number in a status line.

Quick and dirty patch follows:

--- a/src/http/ngx_http_header_filter_module.c
+++ b/src/http/ngx_http_header_filter_module.c
@@ -270,6 +270,12 @@ ngx_http_header_filter(ngx_http_request_
len += NGX_INT_T_LEN;
status_line = NULL;
}
+
+ if (status_line && status_line->len == 0) {
+ status = r->headers_out.status;
+ len += NGX_INT_T_LEN;
+ status_line = NULL;
+ }
}

clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);


--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel