Communicating with different versions of HTTP

One way:

Let "IT" be either the browser, sending a request, or the server sending a document, and let "ME" be the server getting a request or the browser receiving a document.

ME will find in the received data the number v(IT) of the HTTP version used by IT. If this number is different from the version v(ME) it uses itself, then:

v(ME) = v(IT)
No problem.
v(ME) = v(IT)+1:
ME should downgrade to the previous version, which ME is supposed to know. IT will bring the problem to the attention of its user (but see silencing )
v(ME) > v(IT)+1
An alert is given to the user of ME. No further communication can proceed.
All features of HTTP version n and n-1 are always implemented. To implement downgrading, it is sufficient to keep a list of flags. In fact, a set of such lists could be used to downgrade several levels back, but this should not be done.

Another way:

[Tim] This came out of rpc project thinking on version upgrade for client and server software modules which never made it into the software but seemed to cover the needs, and would have solved some real problems in a large distributed system.

Suppose there is a sequence of versions. For each new version, the changes may make a server of that version incompatible with earlier clients before a certain version.

Similarly but independently, a client of the new version may or may not be compatible with servers of earlier versions.

There is a sort of cross-compatibility map but you can simplify it by assuming that if you are incompatible with old version V then you are also incompatible with old versions =Vmin for both s and c and if so all is fine.

This leaves open still the possibility of saying "Please rephrase that". Note I am sticking to the single request-reply model always for speed. RC