W3C home > Mailing lists > Public > public-autowebplatform@w3.org > February 2017

Re: Web socket vs REST security

From: Dave Raggett <dsr@w3.org>
Date: Mon, 20 Feb 2017 15:33:54 +0000
Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Message-Id: <97E6EF73-F58B-4EA5-8F17-3B795369D17B@w3.org>
To: "Bartsch, Patrick, Dr. (I/EE-511)" <patrick.bartsch@audi.de>
Server-Sent Events is defined by the following W3C Recommendation:

    https://www.w3.org/TR/eventsource/

It supports multiple kinds of events over the same connection. I am not aware of any defined payload limits, so these are probably constrained by your server and client code base.  You can get a regular HTTP error response when the client attempts to make the original request to open the connection.

When problems occur (such as a network timeout or issues pertaining to access control), an error event is generated. You can take action on this programmatically by  implementing the onerror callback on the EventSource object.

As far as I know Server Sent Events is supported in Chrome, Firefox, Opera and Safari, but not Internet Explorer, although it is under consideration for Microsoft’s Edge browser, see:

     http://caniuse.com/#feat=eventsource

One the minus side there is no direct support for binary data. On the plus side is automatic connection re-establishment, which can be hard to get right with WebSockets.  Another point on the plus side is that your server can be simplified if it doesn’t need to implement Web Sockets. The extra code for adding Server Sent Events to an existing HTTP server is quite small compared to the additional code needed for WebSockets.


> On 16 Feb 2017, at 20:17, Bartsch, Patrick, Dr. (I/EE-511) <patrick.bartsch@audi.de> wrote:
> 
> We will definetly usw HTTPS in the car for security ans privacy reasons.
> 
> Can you elaborate a little more on SSEs? Can they be used for larger payloads? Will multiple SSE connections share the same TCP ? Can you 'unsubscribe' client side? How will errors be transmitted, will they be sent as payload or can a SSE send natural http response codes instead? Do SSEs have an advantage over we socket in terms of adoption cross platform, in browsers, apps and just plain c libraries?
> 
> Thanks alot for your input
> 
> Best regards
> 
> Dr. Patrick Bartsch
> 
> - sent from my mobile -
> Von: Dave Raggett
> Gesendet: ‎16.‎02.‎2017 20:45
> An: public-autowebplatform@w3.org
> Betreff: Re: Web socket vs REST security
> 
> 
>> On 15 Feb 2017, at 14:02, Ted Guild <ted@w3.org> wrote:
>> 
>> I agree there are two attack surfaces from two protocols. HTTP2’s socket capabilities (which I am not convinced yet serves our needs) would bring the number of protocols down to one.
> 
> My work on web of things demos has shown that Server-Sent events over HTTP is more robust than Web Sockets when it comes to recovering after a dropped connection. It is also easy to extend a simple HTTP server to support server-sent events.  This makes for a one way stream of messages from the server to client, and you would use a regular HTTP PUT, POST or PATCH  for pushing data from the client to the server.
> 
> Something I have yet to explore is client sourced events over HTTP using a long lived connection, and exploiting the HTTP 100 continue response. This could use the same chunked encoding as for server sent events. This is a possibility when you have a data stream from client to server, and may be interesting for connecting from a device inside a firewall to stream telemetry to a server in the cloud.
> 
> Within the car, I guess there is still a case for using HTTPS, but perhaps not that strong given that attackers could have direct access to the car’s components.
> 
> This shows that the discussion should be broader than just Web Sockets vs REST.
> 
> Cheers,
> 
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
> W3C lead for the Web of things
> 
> 
> 

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C lead for the Web of things
Received on Monday, 20 February 2017 15:34:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 20 February 2017 15:34:04 UTC