W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

large file transfers, was: Please admit defeat

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 26 May 2014 11:19:41 +0200
Message-ID: <5383072D.9060308@gmx.de>
To: Yoav Nir <ynir.ietf@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2014-05-26 09:15, Yoav Nir wrote:
>
> On May 26, 2014, at 9:34 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
>>
>> Wouldn't it be faster to go straight after the real goal, an
>> protocol which CAN replace HTTP/1.1 in all scenarios and be
>> an improvement in ALL scenarios ?
>
> Hi
>
> I think that would be a foolís errand. If SPDY has shown us anything, it is that HTTP/1.1 was not optimized for the web(*).  Neither SPDY nor HTTP/2 provide much advantage to the numerous other uses that have cropped up for HTTP: file transfer, web services, streaming media.
>
> In the old days we had different protocols for different use cases. We had FTP and SSH and various protocols for RPC. Placing all our networking needs over HTTP was driven by the ubiquitous availability of HTTP stacks, and the need to circumvent firewalls. I donít believe a single protocol can be optimal in all scenarios. So I believe we should work on the one where the pain is most obvious - the web - and avoid trying to solve everybody elseís problem.
>
> If HTTP/1.1 is not optimal for downloading 4 GB OS updates, let them create their own successor to HTTP/1.1, or use FTP, or use HTTP/2 even though itís not optimal, just like they do today. You canít optimize for everything at once.
> ...

Out of curiosity: exactly how is HTTP/1.1 (or 2) worse than FTP for 
large file transfers?

Best regards, Julian
Received on Monday, 26 May 2014 09:20:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC