Re: should tools like wget implement HTTP 2.0?

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