HTTP streaming about zap HOT 6 OPEN

Sorry for the late reply. Apparently the author of facil.io is working on a new version here which will support streaming w/o blocking a worker thread.

Once this is ready, I consider re-basing zap on top of the new version. This might take a while though, tbh.

from zap.

It seems the existing stable facil.io-0.7 contains an internal function

http_internal.h:

/** Should send existing headers and data and prepare for streaming */
  int (*const http_stream)(http_s *h, void *data, uintptr_t length);

but it does not seem to be used anywhere throughout the code (tried grep *.h and *.c for http_stream). Certainly it is not exposed to the end-user.

The other function below seems to be used in the code:

 /** Should send existing headers or complete streaming */
  void (*const http_finish)(http_s *h);

Perhaps it is time to check out the facil.io 0.8.X development branch but it does not seem to be actively developed right now.

from zap.

Thanks for the info. I thought facil.io had been pretty much "dead", that the new 0.8.X development was stalled. Apparently it is still alive.

from zap.

One more thing: You can consider websockets or even server-side messages as an alternative of streaming. Both are supported by facil.io, and at least web-sockets are wrapped by zap. SSM should be easy enough to wrap, too...

Just some thoughts 😄

from zap.

Yes it's a good thought. Though the WebSockets are already used for streaming real-time binary messages during a normal operation of the web site. The streaming HTTP is used during the initial phase of the web site loading in order to stream real-time compressed output from the gzip (stream compressed chemical molecules whilst the data is being retrieved from the server database), all done prior to opening a WebSocket connection.

There is quite a lot going on "in the background" upon opening a web site. Streaming left and right, establishing the main WebSocket connection - reserved for non-HTTP streaming - etc.

In addition, and this is the main reason for not using WebSockets in this case: the Server-Side Events or WebSocket responses cannot be cached. HTTP streams are treated like normal HTTP responses by caching proxies and web browsers. Therefore I take full advantage of HTTP response caching to avoid HTTP streaming of responses that have already been delivered to the browser before.

from zap.

Thanks but, Server-Side Events (SSE) and WebSocket messages do not support caching by browsers and proxies. HTTP responses are cached, and my application relies on caching. HTTP streams (chunked transfer encoding) are treated like normal HTTP responses and are properly cached.

SSE and WebSockets are not cached (nor should they be). Therefore there is a clear requirement for both HTTP streaming as well as WebSockets. A division of labour, so to speak.

from zap.