3 ms·
Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bear
by Lukasa 12y ago
Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial congestion window on your new connection.
HTTP/2 allows you to avoid that by saying "I'm done with this stream now, sorry!"
- Lukasa 12y agoAh, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(
- jerf 12y agoNo problem, I see I was not clear. Yes, I am specifically curious about the edge case when you "can't" just disconnect the TCP. Scare quoted because I'm sure you can, it just involves something undesirable happening. I have vague ideas and guesses, but I'm curious about what the intent was.
- ashmud 12y agoHow do web browsers handle cancelled requests? Subjectively speaking, it feels like browsers can take a while to recover from cancelling the loading of a large page/page with a large number of assets. Could this be part of that?
- patrickmcmanus 12y agoyou're right. Cancel's in H1 are very painful because all the in-progress transactions have to be torn down completely. New transactions have to set them all up again. H2 let's you just send the server a short message that says "stop sending that stream" and you can go ahead and pipeline a new request right along with that cancel. This happens a lot more than you think as you browse through a collection of things and are just scanning them and clicking the next button - that's a really common use case h2 will handle much better.