News for hackers. Stuff that matters.
Re:Http2 explained by Lukasa on Thursday February 12, 2015 @03:09PM (#9041074)
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!"

Re:Http2 explained by ashmud on Thursday February 12, 2015 @03:38PM (#9041245)
How 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?
Re:Http2 explained by patrickmcmanus on Thursday February 12, 2015 @05:10PM (#9041700)
you'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.

Re:Http2 explained by Lukasa on Thursday February 12, 2015 @03:11PM (#9041079)
Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(
Re:Http2 explained by jerf on Thursday February 12, 2015 @04:05PM (#9041381)
No 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.