5 ms·

You are right, but it's also more nuanced. The remote end can cancel the push if it already has the resource.

Matthias247 8y ago
It can. But the server will only abort streaming once the cancel message reached it. In the worst case that might have already written the whole stream flow control window (64kb) to the socket. So there is some truth to the comment
- vbezhenar 8y ago
  It's especially bad with mobile phones and limited tariffs. Speed could be high but latency also high, so probably a lot of data would be pushed to the socket before client can respond that he doesn't need it. And mobile internet often has very tight limits. HTTP/2 reuses connection, so its speed will be high and TCP windows will be large. A practical example: my phone has 4G connection with 40 Mb/s download speed and 280 ms latency to Seattle. That's a 1.4 MB of data downloaded for 280 ms. I have larger limit, but a lot of people use cheapest Internet plan wit 3 GB limit, so that's a 0,05% of limit just for one request, it'll sum over days pretty quickly.
  - Matthias247 8y ago
    That's a very good remark! I'm currently in a roaming area with a very tight data limit, so this affects me too. I think it might be helpful to have a setting that disables server push for those devices. However the problem here is that most users will neither discover nor understand the setting. Maybe if the ISPs would signal the phone firmware something about the data plan, and that one could switch the push setting it could help, but that's unlikely to happen. Another remedy could be that push implementations on the server only push the headers and don't begin streaming the body, so that the client can check (e.g. through cache and etag comparisons) whether it really wants it. But that's some kind of departure from generic HTTP/2: The client can't really send that it wants the remaining body, since the only signal that it has is the flow control window increment. Clients would need to get modified to send this always when receiving push promises, and servers would need to understand that those should now trigger them to start streaming bodies. If not all do it then it seems like a recipe for stuck requests, and a nightmare for interoperability. So that's also unlikely to happen.

It can. But the server will only abort streaming once the cancel message reached it. In the worst case that might have already written the whole stream flow control window (64kb) to the socket. So there is some truth to the comment

vbezhenar 8y ago
It's especially bad with mobile phones and limited tariffs. Speed could be high but latency also high, so probably a lot of data would be pushed to the socket before client can respond that he doesn't need it. And mobile internet often has very tight limits. HTTP/2 reuses connection, so its speed will be high and TCP windows will be large. A practical example: my phone has 4G connection with 40 Mb/s download speed and 280 ms latency to Seattle. That's a 1.4 MB of data downloaded for 280 ms. I have larger limit, but a lot of people use cheapest Internet plan wit 3 GB limit, so that's a 0,05% of limit just for one request, it'll sum over days pretty quickly.
- Matthias247 8y ago
  That's a very good remark! I'm currently in a roaming area with a very tight data limit, so this affects me too. I think it might be helpful to have a setting that disables server push for those devices. However the problem here is that most users will neither discover nor understand the setting. Maybe if the ISPs would signal the phone firmware something about the data plan, and that one could switch the push setting it could help, but that's unlikely to happen. Another remedy could be that push implementations on the server only push the headers and don't begin streaming the body, so that the client can check (e.g. through cache and etag comparisons) whether it really wants it. But that's some kind of departure from generic HTTP/2: The client can't really send that it wants the remaining body, since the only signal that it has is the flow control window increment. Clients would need to get modified to send this always when receiving push promises, and servers would need to understand that those should now trigger them to start streaming bodies. If not all do it then it seems like a recipe for stuck requests, and a nightmare for interoperability. So that's also unlikely to happen.