I've just tested out a new feature in WAI, which is available for testing
on the raw-response branch[1]. Here's a summary of the change itself and
its purpose. If there are no objections, I'm planning on releasing this as
WAI 2.1.
The goal is to have better support for WebSockets. WAI 2.0 and earlier are
based purely around request/response pairs, without interleaving of reads
and writes. There is some ambiguity about that interleaving when it comes
to streaming responses[1], but essentially, WAI does not currently support
the ability to have bidirectional communications with a client.
The current wai-websockets package ties into a special settings hook
provided by Warp (settingsIntercept). While this works, it makes it
difficult to provide websockets support as a first-class citizen of a web
framework. It also makes creating a WebSockets-aware HTTP reverse proxy
more involved and less efficient.
The proposed change comes down to a single new function in Network.Wai:
responseRaw
:: (C.Source IO B.ByteString -> C.Sink B.ByteString IO () -> IO ())
-> Response
-> Response
This would including a corresponding addition of a ResponseRaw constructor
to Resonse. The idea is that the application would provide a function which
takes a Source of bytes from the client, a Sink for sending bytes to the
client, and the web server would provide that source/sink to the
application. Since not all backends will support responseRaw (e.g., CGI),
there is a requirement for a backup Response to be provided, which will be
used in those cases.
This is a very minor breaking change to the existing API. Only code which
explicitly pattern matches on Response constructors will be affected, and
even there the necessary changes are trivial (see the changes on the
raw-response branch).
Are there any objections to this change, or recommendations for ways to
make it better?
Michael
[1] And in fact, I first tried implementing this change purely using the
existing streaming response interface. However, after attempting it, it
felt like too much of a hack, so I went for the responseRaw approach
instead.
