I have created a HTTPS server from scratch for use in an embedded application.
At present it is able to distinguish between HTTP/1.0 and HTTP/1.1 when it receives a request, and it then subsequently handles the request accordingly. For example, the different means by which connection persistence works is correctly handled according to the HTTP version.
My question relates to how the server should react when it receives a request with a HTTP protocol version higher than 1.1. I'm aware that 2.0 is in the making, but I have no idea when my server is likely to see requests with a version number higher than 1.1. Obviously now is the time to make it future-proof.
Assuming that the server is only ever compliant with RFC2616 (HTTP 1.1) at the most, would the correct response to a request with a protocol higher than 1.1 to be to respond with a HTTP/1.1 response and thereafter handle the transaction as HTTP 1.1?
The present action I am doing is to perform a simple string match to detect HTTP/1.0 or HTTP/1.1 in the request header. If neither are seen, it will deal with the request as if it were HTTP/1.0, which I now do not believe to be correct.
I've been reading RFC2616 again for guidance on this, particularly section 3:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3
But from this, I cannot quite fathom how a server application should respond to a future HTTP version.
The other option I am aware of is to respond with a 505 HTTP Version Not Supported
. Presumably I could return this if I get a request with a version higher than HTTP/1.1. Doing this would, I assume, cause any future browser to make another attempt with a lower HTTP version number, such as HTTP/1.1.
HTTP/1.0 400 Bad Request
. So this is probably more or less the standard way to handle it. Check if protocol downgrade is client or server initiated.curl
to do these tests? I must give that a go myself. TheHTTP/1.0 400
response is a bit of a strange one since presumably that should normally mean the request is malformed and couldn't be parsed.