- From: Yoav Nir <ynir@checkpoint.com>
- Date: Sun, 3 Nov 2013 23:31:51 +0000
- To: Peter Lepeska <bizzbyster@gmail.com>
- CC: Daniel Stenberg <daniel@haxx.se>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <3ABFB2D5-A25F-4A68-919B-FA4D88C6A58B@checkpoint.com>
Hi Peter. See inline. On Nov 3, 2013, at 3:07 PM, Peter Lepeska <bizzbyster@gmail.com<mailto:bizzbyster@gmail.com>> wrote: Hi Yoav, Two things: 1) I think one of the reasons that HTTP has been "wildly popular" is its simplicity. I think we should only give that up if we have to. At the Hyatt bar last night I was talking to an IETFer who is focused on DNS but he has read the HTTP 2 draft and he mentioned that he loves the fact that he can open a telnet prompt and GET files using simple ASCII HTTP. I wouldn't be surprised to hear that 100,000 different HTTP client implementations exist. How many HTTP 2.0 implementations do we expect in 20 years by comparison? [Yoav] I love that telnet ability as well, but that is part of HTTP/0.9. While I can type in "HTTP/1.1", this usually doesn't buy me anything. It's a nice feature of HTTP/1.0 and HTTP/1.1 that they kept this working, and I'm sorry to see it go. I think a simplified HTTP/2 (one resource at a time, no flow control, reject all server push) can be done as an undergraduate project. 2) HTTP 1.x will outperform HTTP 2.x under some conditions and in some implementations due to flow control. I'm worried that flow control HTTP 2.0 implementations will vary and I'll start spending a lot of time debugging HTTP-level flow control in addition to the TCP flow control I already spend a lot of time puzzling over. In addition, in the single stream case, TCP can do flow control much better b/c it gets receive window updates with every ack. Why is HTTP trying to tell the sender how much to send when TCP often knows much better? Flow control is a very complicated business. I think HTTP 2.0 should only do it when it must, and when there is a clear benefit. I agree, and HTTP/2 allows the client to disable flow control. You can do this in the SETTINGS frame, and not worry about flow control at all. I would expect WGET to do this. Thanks for asking, Peter On Sun, Nov 3, 2013 at 1:15 PM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> wrote: On Nov 3, 2013, at 11:56 AM, bizzbyster@gmail.com<mailto:bizzbyster@gmail.com> wrote: > Okay that makes sense. > > But I do have trouble seeing HTTP2 obsoleting HTTP1.1 since for so many purposes it is a step sideways. But let's see how it goes. Hi, Peter I understand what you mean by "sideways", but why is that an obstacle for HTTP/2 replacing HTTP/1.1 ? I could argue that the extra stuff in HTTP/1.0 and HTTP/1.1 are also not quite needed for WGET, and yet that tools did implement HTTP/1.1. Is there some use case where HTTP/2 is inferior? I realize that a minimal implementation is more complicated than a minimal implementation of HTTP/1. But assuming you have both an HTTP/2 and an HTTP/1 implementation, is there a reason to use the HTTP/1 in any case? Yoav Email secured by Check Point
Received on Sunday, 3 November 2013 23:32:42 UTC