0

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.

2
  • Quick check to see what, for example google, is doing revealed that the servers return a 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. Jun 22, 2013 at 12:37
  • Many thanks, Hubert. Are you using a tool such as curl to do these tests? I must give that a go myself. The HTTP/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. Jun 22, 2013 at 12:43

1 Answer 1

0

I'm using telnet within a Linux terminal to type my own raw HTTP requests with various HTTP versions. Here's what I'm finding:

Requests to a Microsoft IIS 7.5 server:

GET / HTTP/1.2 results in the server responding normally, with HTTP/1.1.

GET / HTTP/1.1234 results in the server responding normally, with HTTP/1.1.

GET / HTTP/2.0 results in the server responding with HTTP/1.1 505 HTTP Version Not Supported.

Next I tried against an Apache server. This behaves different in that it always responds happily (e.g. HTTP 200) with HTTP/1.1 even if the major HTTP version in the request is greater than 1. It would serve back pages (rather than throwing 505) even if I used a HTTP version such as 3.1234.

So, according to how the IIS and Apache servers behave:

  • As long as the major HTTP version number is 1, the request shall be handled if the minor version number is greater than 1 (e.g. 1.2, 1.1234) but the response shall state HTTP/1.1.

  • If the major HTTP version number is not 1, then it's down to my decision whether I return 505 HTTP Version Not Supported or handle the request at HTTP/1.1. For simplicity, I'll do the latter.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .