Re: should tools like wget implement HTTP 2.0?

On Sun, Nov 3, 2013 at 3:07 PM, Peter Lepeska <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?
>
>
Having implemented both, I can tell you that it is much more difficult to
make an interoperable HTTP/1.1 implementation than it is to implement the
draft HTTP/2 stuff. Ease and reliability of implementation was the primary
reason for doing binary in the first place!

And yes, text is easier to debug than binary, however, it requires far, far
more debugging.

I have no way of predicting how many HTTP/1.1 implementations will exist in
 X years, but *shrug* I prefer to care about the impact it has where it is
implemented.


> 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.
>
>
TCP knows about TCP stuff, and not application-layer stuff. This creates
optimality problems all over the place. It might be possible to remove one
level of flow control if TCP implementations allowed for much more fine
grained window observation/control, but even then one must be careful since
you don't want to deadlock (and having flow-control apply to control
messages can cause that to occur)!

In any case, I think we all agree that implementations should only do flow
control when they are going to do a good job of it/it is required.

-=R

Thanks for asking,
>
> Peter
>
>
> On Sun, Nov 3, 2013 at 1:15 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>
>>
>> On Nov 3, 2013, at 11:56 AM, 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
>>
>>
>