404 header - HTTP 1.0 or 1.1?

问题:

Why does almost every example I can find (including this question from about a year ago) say that a 404 header should be HTTP/1.0 404 Not Found when we've really been using HTTP 1.1 for over a decade? Is there any reason not to send HTTP/1.1 404 Not Found instead?

(Not that it matters all that much... I'm mostly just curious.)

回答1:

The usage of HTTP version can be based on the following factors:

• Your web server support for HTTP 1.0 or 1.1
• The web browser's support for HTTP 1.0 or 1.1
• Your preference as a web developer on which protocol version to use

Modern browsers can support both 1.0 and 1.1 well, and both the client and server will settle for the highest version both can support together. The key differences between the 2 protocol can be found: http://www8.org/w8-papers/5c-protocols/key/key.html

However there's no key differences in the usage of 404 Not Found. However do be consistent for your whole website. i.e. if you use HTTP/1.1, you use it throughout your website.

回答2:

In PHP you should probably use:

header( $_SERVER['SERVER_PROTOCOL']." 404 Not Found", true );

or even better

header( $_ENV['SERVER_PROTOCOL']." 404 Not Found", true );

(if supported) and thus leave it to the web-server which protocol to use.

Actually, if you pass the status code as 3rd parameter, you can pass whatever you want in the 1st one, as long as it's not empty, and PHP will do the rest. See http://php.net/header

header("foobar", true, 404 );

Also: You can't request a certain protocol version from the client-side since the transaction is hop-to-hop based, and not end-to-end. The server and your browser may very well use HTTP/1.1, but if a proxy inbetween is using only HTTP/1.0, that's what you will see from your client.

回答3:

It does not matter all that much. The client is responsible for telling the server which version of HTTP it uses. Then, the server is supposed to answer with the same version. This does not always happen; I just got this response from a server:

$ telnet example.com 80
Trying 123.123.123.123...
Connected to example.com.
Escape character is '^]'.
GET /fork HTTP/1.0

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 04 May 2010 22:30:36 GMT
Connection: close

I asked the server to use HTTP 1.0, but it went ahead and responded with HTTP 1.1.

回答4:

I'd have thought that the response should be HTTP/1.0 404 Not Found if the request was a HTTP 1.0, and HTTP/1.1 404 Not Found if the request was HTTP 1.1.

In practice, it's going to be easier for servers to returned canned responses, and the HTTP 1.0 response will be understood by both 1.0 and 1.1 clients, so safest to return that. If you know the client understands 1.1 (e.g. because that's what it asked for), then the 1.1 response should work.

Arguably, play it safe and send the 1.0 response.

回答5:

Looking at both the 1.1 and 1.0 RFCs, 404 is there in both - so it's probably for no other reason than for the server to communicate to the client that it's operating on http 1.1.

That said - if a server responds with 404 over Http 1.1, it implies that it could have returned 410 - Gone instead to indicate a resource that used to exist but no longer does. This status code is not part of 1.0, and therefore this information could be useful to a client (especially web crawlers).

EDIT

Sorry - this answer is probably answering the other way around! I reckon you can probably count on only a few hands the number of public web servers that will be bothering to remember all the resources that used to exist and which no longer do (no way I'd code that into my web server!) - so therefore it's probably best to respond with the 1.0 404 to indicate that 'it's just not there' rather than 'that's not here, but other stuff around the site might used to have been but no longer - in which case I could have sent you a 410'.

There's also the fact that you're allowing 1.0-only clients to work with your site.

That said - it's all a bit pedantic.

回答6:

With modern versions of PHP you can also use the http_response_code function and sidestep the problem entirely!

I also like this method because it means that there's no risk of making typos in the response message.