Re: should tools like wget implement HTTP 2.0?

If there is only one stream, then multiplexing isn't terribly interesting,
though flow control (to cap the bandwidth or memory usage) is potentially
useful.

Users of wget, curl, etc. are unlikely to benefit when not doing mirroring
operations (though do when they do). The server may see benefit, however,
even if the user doesn't, especially in the upload case.

-=R
On Nov 3, 2013 9:20 AM, "Peter Lepeska" <bizzbyster@gmail.com> wrote:

>
> On Sun, Nov 3, 2013 at 9:04 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 3 November 2013 08:59,  <bizzbyster@gmail.com> wrote:
>> > Is there any reason why HTTP file transfer clients like curl and wget
>> should
>> > ever implement 2.0?
>>
>> That's not our choice.  Though I would suggest that some of the wget
>> modes of operation would benefit; and there are potentially some
>> advantages to be gained from having opportunistic encryption for http:
>> resources.
>>
>
> Opportunistic encryption would be great if it gets in and I agree that
> then there is a benefit for simple file transfers.
>
>
>>
>> > More radically, since there is no benefit for uploads, should HTTP 2.0
>> even
>> > support the upload verbs?
>>
>> Absolutely yes.  There's more to HTTP PUT than file upload.  And the
>> benefits to proxies and gateways in terms of multiplexing are
>> incredible.
>>
>
> Do you mean the benefit to the proxies of sharing the same TCP connection
> for uploads and downloads? File upload traffic is not responsible for large
> numbers of connections today, is it?
>
> A related point...uploading and downloading large numbers of data frames
> over the same connection is problematic b/c the WINDOW_UPDATE frames will
> get blocked behind data frames in each direction, making flow control
> slower to adapt and so more bursty. Better is just to send the uploads over
> their own TCP connection, I realize this goes against:
>
>    Clients SHOULD NOT open more than one HTTP/2.0 connection to a given
>    origin ([RFC6454 <http://tools.ietf.org/html/rfc6454>]) concurrently.  A client can create additional
>    connections as replacements, either to replace connections that are
>    near to exhausting the available stream identifiers (Section 5.1.1 <http://tools.ietf.org/html/draft-ietf-httpbis-http2-07#section-5.1.1>),
>    or to replace connections that have encountered errors
>    (Section 5.4.1 <http://tools.ietf.org/html/draft-ietf-httpbis-http2-07#section-5.4.1>).
>
>
> But this is only a SHOULD and so user agents are free to choose the better performing approach, which will often be to use multiple TCP connections.
>
>
> Peter
>
>
> Peter
>