3 ms·

Isn't it clear to everyone now that HTTP is the new IP and TCP? That all future protocols will subsist on a web tech substrate? Is that such a bad thing? The vo

Isn't it clear to everyone now that HTTP is the new IP and TCP? That all future protocols will subsist on a web tech substrate? Is that such a bad thing? The vocabulary of URLs and cookies is much richer and less centralized than the vocabulary of port numbers and connection tuples. Why should we keep FTP or other legacy non-HTTP protocols around? What are we buying? Slightly lower connection setup byte counts?

DaiPlusPlus 7y ago
HTTP is objectively better then FTP for downloading files. For remote file management and uploading there are other options besides WebDAV (itself a HTTP protocol extension), such as SSH/SFTP. Basically the only case I can think of that needs FTP are people wanting to access a shared-webhost web-space. And FTP works fine for them already, and they aren’t using Chrome to update their site either - so no loss.
- Proven 7y ago
  It doesn’t matter what is “better” for “people”. If I want to use FTP I will use FTP. Google should be able to do what they want with their browser, and I may choose to use another browser (already done).
aloknnikhil 7y ago
That's a naive statement. Take streaming protocols, as an example, and that alone is reason enough for why you shouldn't it over HTTP. HTTP is inherently stateless. There are many use-cases that are stateful. This leads to high latencies for HTTP streaming since the full state (HTTP headers to tell me who you are and what you want) is sent for every request.
- quotemstr 7y ago
  HTTP these days (via WebSockets) allows for the creation of stateful connections. My idea is that HTTP will just expand to encompass any remaining non-HTTP use cases. HTTP isn't even coupled to TCO anymore!
  - aloknnikhil 7y ago
    Websockets use HTTP only for the initial handshake. The rest of the channel uses the Websocket protocol.
    - quotemstr 7y ago
      Yes. That protocol is effectively part of HTTP now.
      - ivanfon 7y ago
        The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. https://tools.ietf.org/html/rfc6455#section-1.7 https://tools.ietf.org/html/rfc6455#section-1.7
        quotemstr 7y ago
        Effectively. If you do connection setup, service disambiguation, redirects, and so on with HTTP and switch to a non-HTTP interactive protocol, what you've effectively done is create an HTTP sub-protocol, and I don't care what the document you quoted says.
erik_seaberg 7y ago
Nobody is advocating publishing new resources via FTP and neglecting HTTP. I hope every FTP server starts supporting HTTP as well. But that's not how it works. Dropping support is willfully causing link rot.

DaiPlusPlus 7y ago

HTTP is objectively better then FTP for downloading files. For remote file management and uploading there are other options besides WebDAV (itself a HTTP protocol extension), such as SSH/SFTP. Basically the only case I can think of that needs FTP are people wanting to access a shared-webhost web-space. And FTP works fine for them already, and they aren’t using Chrome to update their site either - so no loss.

Proven 7y ago
It doesn’t matter what is “better” for “people”. If I want to use FTP I will use FTP. Google should be able to do what they want with their browser, and I may choose to use another browser (already done).

aloknnikhil 7y ago

That's a naive statement. Take streaming protocols, as an example, and that alone is reason enough for why you shouldn't it over HTTP. HTTP is inherently stateless. There are many use-cases that are stateful. This leads to high latencies for HTTP streaming since the full state (HTTP headers to tell me who you are and what you want) is sent for every request.

quotemstr 7y ago
HTTP these days (via WebSockets) allows for the creation of stateful connections. My idea is that HTTP will just expand to encompass any remaining non-HTTP use cases. HTTP isn't even coupled to TCO anymore!
- aloknnikhil 7y ago
  Websockets use HTTP only for the initial handshake. The rest of the channel uses the Websocket protocol.
  - quotemstr 7y ago
    Yes. That protocol is effectively part of HTTP now.
    - ivanfon 7y ago
      The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. https://tools.ietf.org/html/rfc6455#section-1.7 https://tools.ietf.org/html/rfc6455#section-1.7
      - quotemstr 7y ago
        Effectively. If you do connection setup, service disambiguation, redirects, and so on with HTTP and switch to a non-HTTP interactive protocol, what you've effectively done is create an HTTP sub-protocol, and I don't care what the document you quoted says.

erik_seaberg 7y ago

Nobody is advocating publishing new resources via FTP and neglecting HTTP. I hope every FTP server starts supporting HTTP as well. But that's not how it works. Dropping support is willfully causing link rot.