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

Re: large file transfers, was: Please admit defeat

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Mon, 26 May 2014 12:48:24 +0300
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <0765BE57-6F41-46AE-9113-138960744683@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>

On May 26, 2014, at 12:19 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

> 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?

Translation of text encoding (ASCII/EBCDIC, CR/LF/CRLF)
Listing directories
Getting or putting multiple files based on wildcard with or without user prompt
Slightly less verbose (very slightlyÖ)
With old-style FTP, each resource got its own TCP connection, and so its own flow control. That one we are getting with HTTP/2.

We used to move files using FTP. We moved to HTTP not because it was better, and not because of a lack of client support (all OSes have an FTP client, and all browsers support ftp:// URIs), but because everybody installed a firewall and half of those blocked FTP, but they all let HTTP through.

Received on Monday, 26 May 2014 09:48:55 UTC

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