| This is something we looked into a while ago. There are a number of disadvantages to this approach that were not highlighted. (1)Base64 encoding files makes them larger, this will eliminate the advantage of smaller headers, almost always. Specifically: "Very roughly, the final size of Base64-encoded binary data is equal to 1.37 times the original data size + 814 bytes (for headers)." Source: http://en.wikipedia.org/wiki/Base64#MIME If you want to send/get Binary data and manipulate it on the client side, XHR requests can handle binary data, which can be placed into javascript typed arrays. (2)Concurrency is limited with websocket requests. You can only push one file per socket at a time, and then if you want to start pushing multiple concurrently you'd need to have more websocket connections open. I understand that you can push files one after another through the same socket, but that's not concurrency. On the back end the infrastructure to send different files through different websocket connections and manage the concurreny can get really messy really quickly. With Http requests, you can usually do two requests concurrently from any 1 domain, and then you can load balance across a set of domains. (3) When Socket.io falls back to HTTP polling, you may end up consuming a lot of bandwidth on headers alone. (4) If you're working with something that has cross domain issues, i.e. a WebGL application base64 encoded URLs will not work. They cannot be used, you have to have resources coming from the URL of a CORS accepted domain. In the end it's simpler and more ideal to just push your files through http requests with built in concurrency. |