Hacker News Reader

Comment by Lukasa | Hacker News Reader

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!"

View on HN

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?

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.

Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(

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.

Reply on news.ycombinator.com