Reconsider requirement for 505 response from server on HTTP/1.0 request

[iay]

The current draft says that requesters MUST use HTTP/1.1 or later, which is fair enough: this permits a server to not implement HTTP/1.0 support.

However, the draft also puts a MUST requirement on the server to respond with a 505 status if HTTP/1.0 is used. That's not the same thing and it's not clear why that requirement is there as it seems like an implementation detail.

I'm not aware of any current implementations implementing this requirement correctly.

We should reconsider the MUST 505 requirement. Removing that requirement would not invalidate any implementations currently implementing it properly, but it would simplify the job of writing new clients.

Another aspect we should consider is how hard it is to implement this requirement in the usual server environments (Apache, Tomcat, Jetty, etc.).

[rhyssmith]

Some data points for the last question:

When released, Apache 2.6 (and the current Apache 2.5 dev release) will be able to do with by loading the mod_policy module and adding PolicyVersion enforce HTTP/1.1 to the relevant base config / vhost / directory.

For Apache 2.4 you need to use mod_rewrite. The following works if placed on the vhost/directory:

    RewriteEngine On
    RewriteCond %{SERVER_PROTOCOL} ^HTTP/1\.0$
    RewriteRule ^ - [R=505]

[jbabb27]

Looks like Cache-Control is new to HTTP 1.1, but that is a SHOULD is the spec.

ETag is new to 1.1 and is a MUST in the MDQ spec.

There's also no support for compression in 1.0 afaik, so possible that a misbehaving server could ship back compressed content to a http 1.0 client.

[dsshafer]

Looks like Cache-Control is new to HTTP 1.1, but that is a SHOULD is the spec.

ETag is new to 1.1 and is a MUST in the MDQ spec.

There's also no support for compression in 1.0 afaik, so possible that a misbehaving server could ship back compressed content to a http 1.0 client.

As written, it looks like ETag support is required for both requesters and responders. Specifically, requesters MUST include conditional request headers on subsequent requests for the same URL:

2.4. Request Headers
...
A metadata request to the same URL, after an initial request, MUST
include the following header:

 If-None-Match, see section 3.2 of [RFC7232].

In terms of whether the responder may disallow HTTP 1.0, there's a reference in RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing to rejecting a client's major protocol version, but not the minor version:

A server SHOULD send a response version equal to the highest version
to which the server is conformant that has a major version less than
or equal to the one received in the request. A server MUST NOT send
a version to which it is not conformant. A server can send a 505
(HTTP Version Not Supported) response if it wishes, for any reason,
to refuse service of the client's major protocol version.

If the intent is to disallow MDQ requesters that don't understand cache headers, then it seems to be most correct as written. But if the intent is to allow backward compatibility for requesters that don't understand cache headers, then it seems we'd want to allow HTTP 1.0 requests. (When a responder receives an HTTP 1.0 request, it could still send an HTTP 1.1 response, at least according to RFC 7230).

[nckroy]

I think the intent is to disallow MDQ requesters that don't understand cache headers. Given there are not going to be any MDQ clients that only support HTTP 1.0, we should probably disallow 1.0 as written in the spec, if possible. If not possible to disallow, we could ignore it in the tests and put something in our service documentation about HTTP 1.0 not being supported, but that clients will get responses to 1.0 requests that are 1.1 responses.