Nginx ignoring client's HTTP 1.0 request and respond by HTTP 1.1

I am testing using nginx/php5-fpm, with the code

<?php

header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found"); 
// also tested: header("Status: 404 Not Found");

echo $_SERVER["SERVER_PROTOCOL"];

And force to use HTTP 1.0 with the curl command.

curl -0 -v 'http://www.example.com/test.php'


> GET /test.php HTTP/1.0

< HTTP/1.1 404 Not Found
< Server: nginx
< Date: Sat, 27 Oct 2012 08:51:27 GMT
< Content-Type: text/html
< Connection: close
< 
* Closing connection #0
HTTP/1.0

As you can see I am already requesting using HTTP 1.0, but nginx reply me with HTTP 1.1

Bounty

@MaximDounin, @MichaelHampton already provided an answer to the spec, thanks. I am extending this question a little bit for the future reader:

Q. What are the advantage of responding HTTP 1.1 when a client request for HTTP 1.0? Shouldn't the approach taken by Google more reasonable, i.e. when client request 1.0, response with 1.0?

This is normal and expected behavior, according to RFC 2616:

Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145.

RFC 2145 expands on this:

An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request. An HTTP server MUST NOT send a version for which it is not at least conditionally compliant. A server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request.

An HTTP server MAY send a lower response version, if it is known or suspected that the client incorrectly implements the HTTP specification, but this should not be the default, and this SHOULD NOT be done if the request version is HTTP/1.1 or greater.

What this means in English is: If the client sends an HTTP/1.0 request, either an HTTP/1.0 response or HTTP/1.1 is acceptable, but HTTP/1.1 is preferred.

The reason this is done is so that one end may advertise the highest version of HTTP that it can support, so that the other end may choose to upgrade its protocol support (if possible). Both ends will then decide what protocol version they can both live with. This design also helps to deal with buggy implementations, as RFC 2145 stated.

It was also envisioned at the time that there may be further versions of the HTTP protocol, both minor and major versions, and the rules were meant to help ensure interoperability. Google's RFC-ignorant approach may break once HTTP/2.0 is finalized. (You know it in its draft form as SPDY.)

Q. What are the advantage of responding HTTP 1.1 when a client request for HTTP 1.0?

It's actually sending you an HTTP/1.0-compliant response. It will not use any features such as keepalive that require HTTP/1.1.

The reason for doing this is because it's a cheap way for the server to say:

"hey, I know you sent me a request using HTTP/1.0, but just to let you know I AM capable of HTTP/1.1. and here's the response to your original request: [..]"

(Note: If the server supported a fictional HTTP/1.8, it would respond with that.)

This saves you an additional request in some situations. If you need to GET 3 different URIs from a server, you could send the first one as HTTP/1.0, then move up to the highest version that both you and the server support for the subsequent requests.