6 ms·

HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are

HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.

TazeTSchnitzel 14y ago
WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)
- flatline3 14y ago
  Corporate firewalls are the general boogieman, but in reality, I haven't seen evidence that they're much more than that. To test this, we implemented fallback-to-HTTPS behavior in a very widely used previously non-HTTP client. We then observed the number of clients that failed to connect via our custom protocol, but succeeded in falling back to HTTPS. The numbers were negligible. It's ridiculous that we'd seriously believe that we can't trust that TCP works on the internet. We joke about it being the "interweb", but I see no reason to sow fear, uncertainty, and doubt, and thus and actually turn the interweb into reality.
  - TazeTSchnitzel 14y ago
    Perhaps, but open wifi often only allows 443 and 80.
    - flatline3 14y ago
      That also breaks IMAP(S), SMTP(S), Jabber, AIM, and a slew of other applications. I don't see that we should model the internet architecture on bad technical choices made on a limited number of open wifi networks. Or, we just frame our standard protocol over websockets as an (unfortunate) fallback, if it ever is revealed to be a real problem.
    - ynniv 14y ago
      Port numbers are not protocols.
      - cdcarter 14y ago
        Yes, but many open wifi hotspots at commercial institutions only have 80 and 443 open.
        flatline3 14y ago
        I believe his point is that you can generally carry whatever protocol you want over port 443 (and often port 80). Given how many other things are broken by networks that foolishly only open port 80 and 443, and their (in my experience) relative rarity, I'd suggest that it's not worth bothering with, except possibly as a fall-back to measure the actual number of people trying to use your service behind such a network.
    - gizmo686 14y ago
      Who says port 80 has to be http?
      - cturner 14y ago
        I think 443 will be a better example because (I think) it's harder for a middle party to profile https and see that it is indeed https and not something else.
        gizmo686 14y ago
fusiongyro 14y ago
> HTTP is a huge, hefty, inefficient and complex protocol It's starting to sound like you've never used CORBA.
- flatline3 14y ago
  No, I just have worse things to say about CORBA and the notion of distributed objects in general.
icebraining 14y ago
HTTP implements an architectural style which ensures reliability, scalability, decoupling of systems and support for hypermedia for a complex network of disparate, unreliable systems and networks. Do you have any suggestion that provides the same features, or should we forgo them because HTTP is "hefty"?
- flatline3 14y ago
  > Do you have any suggestion that provides the same features Message passing. That's all HTTP really is, but it's dressed up in a bunch of historical complexity and inefficiency centered around supporting web browsers.
  - icebraining 14y ago
    But do you have any concrete suggestions of protocols, or are you criticizing the choice based on an hypothetical protocol that would be very similar but incompatible with HTTP and all its existing tools (millions of tested and deployed caching servers, load balancers, etc), and for which whole new libraries would have to be written, just so you can make it somewhat more efficient?
    - flatline3 14y ago
      I think you're grossly over-estimating the difficulty of defining a protocol. It's no more difficult than defining the protocol for which you'll use HTTP as transport. Load balancers know how to load balance straight TCP. HTTP caching servers are an HTTP-centric idea. The 'libraries' you'll need can be much, much smaller when all you need is a bit of framing and serialization, instead of a complete complex RFC compliant HTTP client stack.
      - phillmv 14y ago
        Yes, but who cares? You're just sending json down the wire. Fuck it.
      - icebraining 14y ago
darkhorn 14y ago
You can use DSNP but I cannot because shared hosting do not provide that much support. I wish everybody could use it.

TazeTSchnitzel 14y ago

WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)

flatline3 14y ago
Corporate firewalls are the general boogieman, but in reality, I haven't seen evidence that they're much more than that. To test this, we implemented fallback-to-HTTPS behavior in a very widely used previously non-HTTP client. We then observed the number of clients that failed to connect via our custom protocol, but succeeded in falling back to HTTPS. The numbers were negligible. It's ridiculous that we'd seriously believe that we can't trust that TCP works on the internet. We joke about it being the "interweb", but I see no reason to sow fear, uncertainty, and doubt, and thus and actually turn the interweb into reality.
- TazeTSchnitzel 14y ago
  Perhaps, but open wifi often only allows 443 and 80.
  - flatline3 14y ago
    That also breaks IMAP(S), SMTP(S), Jabber, AIM, and a slew of other applications. I don't see that we should model the internet architecture on bad technical choices made on a limited number of open wifi networks. Or, we just frame our standard protocol over websockets as an (unfortunate) fallback, if it ever is revealed to be a real problem.
  - ynniv 14y ago
    Port numbers are not protocols.
    - cdcarter 14y ago
      Yes, but many open wifi hotspots at commercial institutions only have 80 and 443 open.
      - flatline3 14y ago
        I believe his point is that you can generally carry whatever protocol you want over port 443 (and often port 80). Given how many other things are broken by networks that foolishly only open port 80 and 443, and their (in my experience) relative rarity, I'd suggest that it's not worth bothering with, except possibly as a fall-back to measure the actual number of people trying to use your service behind such a network.
  - gizmo686 14y ago
    Who says port 80 has to be http?
    - cturner 14y ago
      I think 443 will be a better example because (I think) it's harder for a middle party to profile https and see that it is indeed https and not something else.
      - gizmo686 14y ago

fusiongyro 14y ago

> HTTP is a huge, hefty, inefficient and complex protocol It's starting to sound like you've never used CORBA.

flatline3 14y ago
No, I just have worse things to say about CORBA and the notion of distributed objects in general.

icebraining 14y ago

HTTP implements an architectural style which ensures reliability, scalability, decoupling of systems and support for hypermedia for a complex network of disparate, unreliable systems and networks. Do you have any suggestion that provides the same features, or should we forgo them because HTTP is "hefty"?

flatline3 14y ago
> Do you have any suggestion that provides the same features Message passing. That's all HTTP really is, but it's dressed up in a bunch of historical complexity and inefficiency centered around supporting web browsers.
- icebraining 14y ago
  But do you have any concrete suggestions of protocols, or are you criticizing the choice based on an hypothetical protocol that would be very similar but incompatible with HTTP and all its existing tools (millions of tested and deployed caching servers, load balancers, etc), and for which whole new libraries would have to be written, just so you can make it somewhat more efficient?
  - flatline3 14y ago
    I think you're grossly over-estimating the difficulty of defining a protocol. It's no more difficult than defining the protocol for which you'll use HTTP as transport. Load balancers know how to load balance straight TCP. HTTP caching servers are an HTTP-centric idea. The 'libraries' you'll need can be much, much smaller when all you need is a bit of framing and serialization, instead of a complete complex RFC compliant HTTP client stack.
    - phillmv 14y ago
      Yes, but who cares? You're just sending json down the wire. Fuck it.
    - icebraining 14y ago

darkhorn 14y ago

You can use DSNP but I cannot because shared hosting do not provide that much support. I wish everybody could use it.