As Phil encouraged me in our private thread,... the following ticket as a place where such a long term plan can be recorded/discussed.
SKS should perhaps support HTTP 1.1 at the long term (or later maybe even newer versions).
I told you guys my (of course just personal) opinion that SKS shouldn't be a webserver, but (with respect to HKP) rather just a HTTP speaking backend to speak to a reverse-proxy in front of it, which does all the communication with the client and also serving the frontend websites. So from that one could say there is not strong need to support versions newer than HTTP 1.0 (or at a later point even 2.0).
The only problem I see with not supporting 1.1 are the following tow:
1) As Phil already points out to some extent at the wiki, there is that issue with HTTP1.0/1.1 compatibility, that could lead to 417 errors.
I read a lot through the respective RFCs, and the standards say, when a reverse-proxy knows that the backend is HTTP 1.0-only and the proxy sees a Expect: 100-continue header, it MUST answer it with a 417 error.
Now SKS is HTTP 1.0-only and in principle that kicks in... of course we can simply drop the header or "not tell" the proxy server that the backend is HTTP1.0... but both is IMHO rather a violation of the standards. And the standard is right with mandating that behaviour... since what we do now is breaking the expected behaviour of what 100-expect should give, namely a way for the client to see whether the server is "ready" to go on with actual things.
So as far as I can tell… this is not a problem of the proxy (i.e. Apache) but of the HKP clients that should not use 100-continue.
As Phil pointed out, curl sends 100-continues per default, and as far as I can tell, it even does that in a standard incompatible way (there are even threads at upstream about this), as it doesn't do what the RFCs mandate when using 100-continue (wait for a 100 response and only then send further requests/content), but sends a body along with the 100-continue. This seems to be the only reason why simply droping the Expect header is now a solution for us as SKS operators.
Of course dropping the whole Expect header has another drawback, namely that there may be future extensions to it other than 100-continue... or perhaps even private ones, that may be used at a site.
2) The second problem I can see, is that HTTP 1.0 doesn't support chunked encoding, though many HTTP1.1 speaking clients may use that on post... and it would likely also more performant for our responses. So right now, we either have to force the use of Content-Length all the way, or the reverse proxy has to do additional work in converting from CL to CE and vice-versa.