Bug 6003 - tlwebadm and tlwebaccess doesn't support HTTP/1.1
Summary: tlwebadm and tlwebaccess doesn't support HTTP/1.1
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Peter Åstrand
URL:
Keywords:
Depends on: 8229
Blocks: 6004
  Show dependency treegraph
 
Reported: 2016-09-22 14:04 CEST by Samuel Mannehed
Modified: 2023-09-19 13:16 CEST (History)
3 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Samuel Mannehed cendio 2016-09-22 14:04:34 CEST
HTTP/1.1 supports modern features like multiple requests over one connection. Supporting it would make our services better.
Comment 1 Samuel Mannehed cendio 2016-10-05 13:43:06 CEST
See bug 6020 for HTTP/2
Comment 2 Samuel Mannehed cendio 2017-01-25 15:13:35 CET
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.
Comment 4 Samuel Mannehed cendio 2017-01-26 10:30:07 CET
(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.
Comment 5 Linn cendio 2022-10-19 11:27:06 CEST
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.
Comment 6 Pierre Ossman cendio 2022-11-16 16:44:43 CET
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.
Comment 7 Pierre Ossman cendio 2023-01-30 13:53:20 CET
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.
Comment 8 Pierre Ossman cendio 2023-09-08 09:28:51 CEST
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.)

Note You need to log in before you can comment on or make changes to this bug.