HTTP/1.1 supports modern features like multiple requests over one connection. Supporting it would make our services better.
See bug 6020 for HTTP/2
It seems like HTTP/1.1 expands caching support by introducing new tags used in headers and other things: http://stackoverflow.com/questions/246859/http-1-0-vs-1-1 https://tools.ietf.org/html/rfc7234 https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching After upgrading ThinLinc, recent versions of Safari doesn't clear the cache automatically. My guess is that this happens because we do not use any of these new HTTP/1.1 caching mechanisms which Safari seems to depend on. The workaround for this is obviously to manually clear the browser cache. But when implementing this bug, we should take this into account.
(In reply to comment #2) > It seems like HTTP/1.1 expands caching support by introducing new tags used in > headers and other things: > > http://stackoverflow.com/questions/246859/http-1-0-vs-1-1 > https://tools.ietf.org/html/rfc7234 > https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching > > After upgrading ThinLinc, recent versions of Safari doesn't clear the cache > automatically. My guess is that this happens because we do not use any of these > new HTTP/1.1 caching mechanisms which Safari seems to depend on. > > The workaround for this is obviously to manually clear the browser cache. But > when implementing this bug, we should take this into account. Actually, we don't even have basic cache control in our web server. See bug 5711.
This issue is made worse in tlwebaccess since websockets do not support HTTP/1.0. At the moment, we just swap the protocol to HTTP/1.1 before using the websockets.
We also need to check the timeout system when doing this. We have code that makes sure timeouts are per request, not per connection, but I'm unsure if we have unit tests for it. Not only that, but we also fail to account for the fact that authenticated requests shouldn't have a timeout in that code.
Note that HTTP/1.0 had some cache handling in practice, via the Pragma: header. We make use of this in tlwebadm. We should change this usage to something more modern as part of the switch to HTTP/1.1.
HTTP/1.1 also adds the Transfer-Encoding header with mandatory support for chunked. This means we need to be prepared to parse such data when we get form data. (There is the oddity of how does the browser know that the server supports HTTP/1.1? It can't on the first connection, but the specification states that the browser might rely on out-of-band data, or remember it from previous connections. It also wouldn't surprise me if browsers start assuming that everything supports HTTP/1.1 given its age.)
