12 ms·

I think this (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0816.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...) follow-up m

I think this (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0816.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...) follow-up makes a valid point: > 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 we're not careful, we're just going to end up cycling back around again and find ourselves 20 years in the past. That said, I do think to some extent "that ship has sailed". The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol". See, for example, STOMP over WebSockets. While it is annoying that this implies we've added a layer to the model, it's hard to argue with the real-world portability/ease of development that this all has enabled.

pjc50 12y ago
The importance of firewall punching can't be overstated. There are plenty of end users in workplaces or on other people's wifi who find that all outgoing ports other than 80 and 443 are blocked. Yes, this is incredibly stupid, but they're not going to do anything about it.
- skrebbel 12y ago
  So we tunnel everything through 80/443, and then proxies are going to deep packet inspect that, and selectively block some over-http protocols, so we're going to tunnel stuff through a more innocuous looking protocol over HTTP, and tunnel through the tunnel through the tunnel through the tunnel. I propose OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP as the new de-facto standard connection protocol. Maybe we can FTP through that VPN connection some time, please wait while I cook up a JavaScript FTP/OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP client.
  - gtirloni 12y ago
    Looked like a good idea until you mentioned JavaScript. Bummer.
    - tylerlh 12y ago
      If you're so against a js client, you could certainly whip one up in another language...
      - gtirloni 12y ago
        Whoosh... EDIT: A OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP is a terrible idea and I'm assuming it was meant as a joke. Thus, the addition of Javascript to the comment makes no difference at all. Thus, my comment was intended as a joke since it's irrelevant (again) in which language a bad proposal is implemented. There, you took all the fun out of it. Happy? ;-)
        mst 12y ago
        If it's any consolation, I laughed harder at this than I did at the original joke.
        deleted 12y ago
        [deleted]
        tylerlh 12y ago
        I guess I'm naive and think that comments on HN should try to be constructive, so your sarcasm did miss me. If the proposed idea is a bad one, don't you think it would have been much more helpful if you added your opinion on that to the convo rather than snark? My apologies for ruining your fun.
        ehsanu1 12y ago
        The original "idea" itself was itself sarcasm. Your parent was simply underscoring it. You just failed to identify the original sarcasm, and ended up confused and a bit too serious about it all. It's just some obscure humor, no need to get worked up over it :)
- josteink 12y ago
  So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP. And thus naturally HTTP must be made to accommodate for all those applications. You may think that makes sense, but you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence. Besides, if that's the path we're walking, DPI-based firewall with HTTP-level application firewalling will become the new norm, and we've gotten nowhere further. Except we now have a even bigger mess to work with. While the OSI-model may be going a bit over board for some aspects, making all future application-protocols be a squashed through HTTP is madness. This thinking is of the same quality and mindset as of PHP developers.
  - lmm 12y ago
    > you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence On the contrary, the only reason the internet works is because it's robust enough to survive incompetent network admins.
  - pjc50 12y ago
    I did not say that. What I am saying is that applications of the future that tunnel over HTTP will be much, much wider adopted than those that don't. Regardless of how suitable it is for the purpose. I'm not saying this imposes any constraint on the HTTP designers. Tunnelling will probably have to be HTTPS everywhere too as a countermeasure against both surveillance and DPI. Arguably the internet is a hack around incompetence and power-hoarding; the phone companies potentially had the technology to deliver many of the things we see as internet services as early as the 1980s, but were too bureaucratic to deliver innovation and especially cost reductions. (Compare MINITEL, for example) That the internet makes service-based billing hard is also a feature.
  - alephnil 12y ago
    > So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP. The product I work with has some protocols that is non-http. Some of our customers are complaining to us because _their_ users can't get through their own firewall (i.e the users own firewall, not our customers firewall). These users are often on corporate networks, and to get the users to convince their employer to fix their firewall is likely a waste of energy. In fact our customers may consider to switch to another vendor if we don't change to a HTTP based protocol. Of cause the same firewall administrators may introduce deep packet inspection to only allow real web traffic later, creating more problems, but as someone delivering third party solutions now, you are forced to use HTTP or HTTPS.
- andybalholm 12y ago
  On the other hand, there are firewall administrators who do extensive filtering on ports 80 and 443 and allow other outgoing traffic by default. We get pretty ticked off when some thermostat, credit card machine, or postage meter decides to send its bizarre and undocumented data stream over port 80 or 443 in the name of firewall compatibility and therefore becomes incompatible with our firewall. (Yes, we can put in exceptions for those machines' IP addresses, but if they didn't try to use HTTP ports, they would Just Work.)
  - aktau 12y ago
    Let me tell you that where I live, networks like yours are the minority. Sadly, when 99% are going for the 80/443 are free and the rest forget-about-it, I'm going to "tunnel" my stuff over 443 because I don't like being called 10-20 times a day with "nothing works"-type complaints that I can't properly remotely debug because obviously, nothing works. Edit: my "tunnel" is actually WebSockets over SSL on port 443. Not sure if you guys would block that as supposedly this should be no different from, say, gmail or facebook traffic.
    - andybalholm 12y ago
      Yes, websockets should be fine. Making my proxy support websockets was a little difficult, but I think it works now. If the traffic is compliant with the protocols that ports 80 and 443 are supposed to use, it's not a problem. The one that really gets me is a thermostat using a proprietary protocol over port 443. This protocol is one where the server sends the first data over the connection; in TLS the client always sends first. So my proxy was just waiting for the TLS client hello while the thermostat was waiting for its server's message. If the thermostat had sent something first, the proxy could have seen that it was invalid TLS and passed it through; instead it deadlocked.
- simon_vetter 12y ago
  Until a big enough player decides to use something else. Case in point: 5223/tcp, used by Apple's Push Notification service (amongst other things). Push notifications not being delivered to so many networks made their users angry and tech support calls (and costs) boom, and had soon 5223/tcp unblocked, even on free, non-encrypted, coffee-shop wifi networks. I understand that most developers just choose to roll with it these days, but I really believe that putting everything atop of 443/tcp because of clueless/incompetent sysadmins is a huge mistake. Keeping protocol stacks small, efficient and secure should be a design goal.
  - dsl 12y ago
    > because of clueless/incompetent sysadmins is a huge mistake I think clueless is a little strong. We've just gotten to a time where the usual connection between network administrators and users is pretty loose. You don't actually know who is running that coffee shop wifi, so you can't ask for your applications to be unblocked.
- peterwwillis 12y ago
  Here's why I think firewall punching is stupid and should not be supported. IP addresses are logical numbers used to communicate with a host. In order to make it easier for humans to know what host to communicate with, DNS records were created to be able to easily communicate with a particular host. In addition to figuring out what host we want to communicate with we need a way to specify what application we want to use. So service names were created and assigned to a static list of application port numbers. Two of these application service names are "http" and "https", which each provide a different application protocol. We've built so many things that depend on these two application protocols that developers have finally outgrown what the protocols are capable of. But to get support for a new protocol is "hard". You have to do three things to successfully roll out a new application protocol: 1. Write a server for it and make people want to use it, 2. Write a client for it and get users to want to use it, 3. Get network administrators to open up their firewalls to support it. Sadly, many developers are playing a cat-and-mouse game with network administrators. They want their applications to be used by anyone, anywhere, automatically. So they employ tricks to get their content past network administrators, like re-using the same application service names used by protocols which are ubiquitously supported throughout worldwide networks. But this just creates an arms race with network admins. For example, mandating strong encryption to use a service means a network admin traditionally can't restrict what kind of applications work over it. So in order to fight their users subverting their approved applications policies, more and more organizations are doing SSL inspection by injecting CA certs into their employees' computers to block unauthorized applications. Fighting network admins is a losing game, and does not benefit the users of your applications, or the developers. Instead of hiding more features and overlaying protocols, it would be more productive to create protocols that use their own service names and provide their own functionality and let users demand it be supported by the network admins. This is how all popular application services have been adopted over the years and provides the best quality of service to everyone involved.
icebraining 12y ago
The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol". It's not like WebSockets runs "over" HTTP, it just uses an HTTP-like handshake; besides that, it's just a simple framing protocol over TCP. That's why you can use a simple proxy to "websocket-ify" applications that use plain-old raw TCP connections.
- jballanc 12y ago
  Right, that's why I said we're adding one layer (not two). Still, if TCP is the transport layer, and HTTP/SMTP/etc. are the application layer, then what do we call WebSockets when we implement an application layer protocol on top of it? The application compatibility layer? In the past we had operating systems with network stacks and shared libraries for working with application protocols. Now we have browsers with network stacks and JavaScript libraries for working with application protocols. Wasn't it just a few days ago that someone was proposing an OS that would do just enough to boot a browser, and then let the browser handle most of the "traditional" operating system tasks? How long before we see a proposal for "lowering" WebSocket connections to the TCP layer? This is what I mean when I say that we risk finding ourselves 20 years in the past. HTTP isn't ubiquitous because it is better. It's better because it is ubiquitous. If we don't pay attention to why things like WebSockets are easier to use today than raw TCP, then history will repeat itself.
  - M2Ys4U 12y ago
    >Wasn't it just a few days ago that someone was proposing an OS that would do just enough to boot a browser, and then let the browser handle most of the "traditional" operating system tasks? We already have that - Firefox OS: https://www.mozilla.org/en-US/firefox/os/ https://www.mozilla.org/en-US/firefox/os/
  - mattgreenrocks 12y ago
    Preach it. I haven't seen anything that actually requires a new OSI layer, only people trying to reinvent lower-level layers poorly to address gross incompetence. The Internet is more than the Web, and the Web will eventually be replaced.

pjc50 12y ago

The importance of firewall punching can't be overstated. There are plenty of end users in workplaces or on other people's wifi who find that all outgoing ports other than 80 and 443 are blocked. Yes, this is incredibly stupid, but they're not going to do anything about it.

skrebbel 12y ago
So we tunnel everything through 80/443, and then proxies are going to deep packet inspect that, and selectively block some over-http protocols, so we're going to tunnel stuff through a more innocuous looking protocol over HTTP, and tunnel through the tunnel through the tunnel through the tunnel. I propose OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP as the new de-facto standard connection protocol. Maybe we can FTP through that VPN connection some time, please wait while I cook up a JavaScript FTP/OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP client.
- gtirloni 12y ago
  Looked like a good idea until you mentioned JavaScript. Bummer.
  - tylerlh 12y ago
    If you're so against a js client, you could certainly whip one up in another language...
    - gtirloni 12y ago
      Whoosh... EDIT: A OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP is a terrible idea and I'm assuming it was meant as a joke. Thus, the addition of Javascript to the comment makes no difference at all. Thus, my comment was intended as a joke since it's irrelevant (again) in which language a bad proposal is implemented. There, you took all the fun out of it. Happy? ;-)
      - mst 12y ago
        If it's any consolation, I laughed harder at this than I did at the original joke.
      - deleted 12y ago
        [deleted]
      - tylerlh 12y ago
        I guess I'm naive and think that comments on HN should try to be constructive, so your sarcasm did miss me. If the proposed idea is a bad one, don't you think it would have been much more helpful if you added your opinion on that to the convo rather than snark? My apologies for ruining your fun.
        ehsanu1 12y ago
        The original "idea" itself was itself sarcasm. Your parent was simply underscoring it. You just failed to identify the original sarcasm, and ended up confused and a bit too serious about it all. It's just some obscure humor, no need to get worked up over it :)
josteink 12y ago
So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP. And thus naturally HTTP must be made to accommodate for all those applications. You may think that makes sense, but you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence. Besides, if that's the path we're walking, DPI-based firewall with HTTP-level application firewalling will become the new norm, and we've gotten nowhere further. Except we now have a even bigger mess to work with. While the OSI-model may be going a bit over board for some aspects, making all future application-protocols be a squashed through HTTP is madness. This thinking is of the same quality and mindset as of PHP developers.
- lmm 12y ago
  > you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence On the contrary, the only reason the internet works is because it's robust enough to survive incompetent network admins.
- pjc50 12y ago
  I did not say that. What I am saying is that applications of the future that tunnel over HTTP will be much, much wider adopted than those that don't. Regardless of how suitable it is for the purpose. I'm not saying this imposes any constraint on the HTTP designers. Tunnelling will probably have to be HTTPS everywhere too as a countermeasure against both surveillance and DPI. Arguably the internet is a hack around incompetence and power-hoarding; the phone companies potentially had the technology to deliver many of the things we see as internet services as early as the 1980s, but were too bureaucratic to deliver innovation and especially cost reductions. (Compare MINITEL, for example) That the internet makes service-based billing hard is also a feature.
- alephnil 12y ago
  > So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP. The product I work with has some protocols that is non-http. Some of our customers are complaining to us because _their_ users can't get through their own firewall (i.e the users own firewall, not our customers firewall). These users are often on corporate networks, and to get the users to convince their employer to fix their firewall is likely a waste of energy. In fact our customers may consider to switch to another vendor if we don't change to a HTTP based protocol. Of cause the same firewall administrators may introduce deep packet inspection to only allow real web traffic later, creating more problems, but as someone delivering third party solutions now, you are forced to use HTTP or HTTPS.
andybalholm 12y ago
On the other hand, there are firewall administrators who do extensive filtering on ports 80 and 443 and allow other outgoing traffic by default. We get pretty ticked off when some thermostat, credit card machine, or postage meter decides to send its bizarre and undocumented data stream over port 80 or 443 in the name of firewall compatibility and therefore becomes incompatible with our firewall. (Yes, we can put in exceptions for those machines' IP addresses, but if they didn't try to use HTTP ports, they would Just Work.)
- aktau 12y ago
  Let me tell you that where I live, networks like yours are the minority. Sadly, when 99% are going for the 80/443 are free and the rest forget-about-it, I'm going to "tunnel" my stuff over 443 because I don't like being called 10-20 times a day with "nothing works"-type complaints that I can't properly remotely debug because obviously, nothing works. Edit: my "tunnel" is actually WebSockets over SSL on port 443. Not sure if you guys would block that as supposedly this should be no different from, say, gmail or facebook traffic.
  - andybalholm 12y ago
    Yes, websockets should be fine. Making my proxy support websockets was a little difficult, but I think it works now. If the traffic is compliant with the protocols that ports 80 and 443 are supposed to use, it's not a problem. The one that really gets me is a thermostat using a proprietary protocol over port 443. This protocol is one where the server sends the first data over the connection; in TLS the client always sends first. So my proxy was just waiting for the TLS client hello while the thermostat was waiting for its server's message. If the thermostat had sent something first, the proxy could have seen that it was invalid TLS and passed it through; instead it deadlocked.
simon_vetter 12y ago
Until a big enough player decides to use something else. Case in point: 5223/tcp, used by Apple's Push Notification service (amongst other things). Push notifications not being delivered to so many networks made their users angry and tech support calls (and costs) boom, and had soon 5223/tcp unblocked, even on free, non-encrypted, coffee-shop wifi networks. I understand that most developers just choose to roll with it these days, but I really believe that putting everything atop of 443/tcp because of clueless/incompetent sysadmins is a huge mistake. Keeping protocol stacks small, efficient and secure should be a design goal.
- dsl 12y ago
  > because of clueless/incompetent sysadmins is a huge mistake I think clueless is a little strong. We've just gotten to a time where the usual connection between network administrators and users is pretty loose. You don't actually know who is running that coffee shop wifi, so you can't ask for your applications to be unblocked.
peterwwillis 12y ago
Here's why I think firewall punching is stupid and should not be supported. IP addresses are logical numbers used to communicate with a host. In order to make it easier for humans to know what host to communicate with, DNS records were created to be able to easily communicate with a particular host. In addition to figuring out what host we want to communicate with we need a way to specify what application we want to use. So service names were created and assigned to a static list of application port numbers. Two of these application service names are "http" and "https", which each provide a different application protocol. We've built so many things that depend on these two application protocols that developers have finally outgrown what the protocols are capable of. But to get support for a new protocol is "hard". You have to do three things to successfully roll out a new application protocol: 1. Write a server for it and make people want to use it, 2. Write a client for it and get users to want to use it, 3. Get network administrators to open up their firewalls to support it. Sadly, many developers are playing a cat-and-mouse game with network administrators. They want their applications to be used by anyone, anywhere, automatically. So they employ tricks to get their content past network administrators, like re-using the same application service names used by protocols which are ubiquitously supported throughout worldwide networks. But this just creates an arms race with network admins. For example, mandating strong encryption to use a service means a network admin traditionally can't restrict what kind of applications work over it. So in order to fight their users subverting their approved applications policies, more and more organizations are doing SSL inspection by injecting CA certs into their employees' computers to block unauthorized applications. Fighting network admins is a losing game, and does not benefit the users of your applications, or the developers. Instead of hiding more features and overlaying protocols, it would be more productive to create protocols that use their own service names and provide their own functionality and let users demand it be supported by the network admins. This is how all popular application services have been adopted over the years and provides the best quality of service to everyone involved.

icebraining 12y ago

The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol". It's not like WebSockets runs "over" HTTP, it just uses an HTTP-like handshake; besides that, it's just a simple framing protocol over TCP. That's why you can use a simple proxy to "websocket-ify" applications that use plain-old raw TCP connections.

jballanc 12y ago
Right, that's why I said we're adding one layer (not two). Still, if TCP is the transport layer, and HTTP/SMTP/etc. are the application layer, then what do we call WebSockets when we implement an application layer protocol on top of it? The application compatibility layer? In the past we had operating systems with network stacks and shared libraries for working with application protocols. Now we have browsers with network stacks and JavaScript libraries for working with application protocols. Wasn't it just a few days ago that someone was proposing an OS that would do just enough to boot a browser, and then let the browser handle most of the "traditional" operating system tasks? How long before we see a proposal for "lowering" WebSocket connections to the TCP layer? This is what I mean when I say that we risk finding ourselves 20 years in the past. HTTP isn't ubiquitous because it is better. It's better because it is ubiquitous. If we don't pay attention to why things like WebSockets are easier to use today than raw TCP, then history will repeat itself.
- M2Ys4U 12y ago
  >Wasn't it just a few days ago that someone was proposing an OS that would do just enough to boot a browser, and then let the browser handle most of the "traditional" operating system tasks? We already have that - Firefox OS: https://www.mozilla.org/en-US/firefox/os/ https://www.mozilla.org/en-US/firefox/os/
- mattgreenrocks 12y ago
  Preach it. I haven't seen anything that actually requires a new OSI layer, only people trying to reinvent lower-level layers poorly to address gross incompetence. The Internet is more than the Web, and the Web will eventually be replaced.