3 ms·

HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten abou

HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten about machine somewhere on the path.

dagenix 7y ago
Pipelining support in http 1.1 is basically useless even outside of the compatibility issues.
- rkeene2 7y ago
  I built a server-side mouse tracking over HTTP application that used HTTP/1.1 Pipelining to increase precision [0], back when web browsers supported HTTP/1.1 Pipelining, that is. [0] https://github.com/rkeene/webdraw https://github.com/rkeene/webdraw
  - dagenix 7y ago
    That does sound pretty cool. But it sounds like a fairly special case where the responses were likely uniformly small, which is unusual for a more general use case. Given somewhat more recent technology, it sounds like a great use case for something like WebSockets.
    - rkeene2 7y ago
      Yeah, WebSockets would also work here -- I would need to invent an ad-hoc protocol for making the resource requests, and it would be similar to a mini HTTP/1.1 Pipelining in spirit. The project needs some other work, since it looks like changes to Chrome have broken the mouse tracking. [0] http://webdraw.rkeene.org/ http://webdraw.rkeene.org/
- toast0 7y ago
  Pipelining in 1.1 has some issues, but it could be useful in the right circumstances (except that, there's not a lot of implementations of pipelining, so chances are the other end won't do it). The perfect use case for pipelining is when the client is connected to a (reverse) proxy near to it, is making retryable requests, the origin is far from the proxy, and the requests don't take much time for the origin to process. You can also get benefits if there is a proxy near the server and the requests take significant time to process, but the proxy can divide them over multiple servers (or the server handles pipelining and divides over multiple threads). The way these usecases are met instead is through multiple TCP connections, or multiple multiplexed streams in HTTP/2 (and beyond). There's certainly benefits of individual streams, but there's costs too, so it's unfortunate that the http/1.1 way was stiffled.
  - dagenix 7y ago
    In both of those cases it's also important that the responses be small, since, due to pipelining requiring that responses come back in the same order as requests, you have to buffer up any responses that become ready out of order. Also, the response time for each request needs to be about the same or you have to issue requests in the right order, or, you end up potentially blocking every response due to the first one taking the longest. HTTP pipelining isn't largely unimplemented because people were lazy - its largely unimplemented because its easy to DOS a server, possibly by accident, and there are significant latency issues due to head-of-line blocking with slow requests.
yencabulator 7y ago
Another example: Setting Allow header properly in a 405 response is a MUST. I am not aware of anything that breaks due to missing that, and I am aware of many implementations that do not set it.

HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten about machine somewhere on the path.

dagenix 7y ago

Pipelining support in http 1.1 is basically useless even outside of the compatibility issues.

rkeene2 7y ago
I built a server-side mouse tracking over HTTP application that used HTTP/1.1 Pipelining to increase precision [0], back when web browsers supported HTTP/1.1 Pipelining, that is. [0] https://github.com/rkeene/webdraw https://github.com/rkeene/webdraw
- dagenix 7y ago
  That does sound pretty cool. But it sounds like a fairly special case where the responses were likely uniformly small, which is unusual for a more general use case. Given somewhat more recent technology, it sounds like a great use case for something like WebSockets.
  - rkeene2 7y ago
    Yeah, WebSockets would also work here -- I would need to invent an ad-hoc protocol for making the resource requests, and it would be similar to a mini HTTP/1.1 Pipelining in spirit. The project needs some other work, since it looks like changes to Chrome have broken the mouse tracking. [0] http://webdraw.rkeene.org/ http://webdraw.rkeene.org/
toast0 7y ago
Pipelining in 1.1 has some issues, but it could be useful in the right circumstances (except that, there's not a lot of implementations of pipelining, so chances are the other end won't do it). The perfect use case for pipelining is when the client is connected to a (reverse) proxy near to it, is making retryable requests, the origin is far from the proxy, and the requests don't take much time for the origin to process. You can also get benefits if there is a proxy near the server and the requests take significant time to process, but the proxy can divide them over multiple servers (or the server handles pipelining and divides over multiple threads). The way these usecases are met instead is through multiple TCP connections, or multiple multiplexed streams in HTTP/2 (and beyond). There's certainly benefits of individual streams, but there's costs too, so it's unfortunate that the http/1.1 way was stiffled.
- dagenix 7y ago
  In both of those cases it's also important that the responses be small, since, due to pipelining requiring that responses come back in the same order as requests, you have to buffer up any responses that become ready out of order. Also, the response time for each request needs to be about the same or you have to issue requests in the right order, or, you end up potentially blocking every response due to the first one taking the longest. HTTP pipelining isn't largely unimplemented because people were lazy - its largely unimplemented because its easy to DOS a server, possibly by accident, and there are significant latency issues due to head-of-line blocking with slow requests.

yencabulator 7y ago

Another example: Setting Allow header properly in a 405 response is a MUST. I am not aware of anything that breaks due to missing that, and I am aware of many implementations that do not set it.