Closed kkazuo closed 7 years ago
Hi.
I have just implement this feature with a ?request_cb
argument.
Look at websocket_async.mli
and wscat_async.ml
for an example.
Please give me your feedback on this.
Thank you for the quick reply!
In my usecase, a client send jwt id token:
ws://localhost:8080/doc?token=ey.ey.
then the server validate the token and establish a websocket if it's ok, otherwise
400 Bad Request
response and close the HTTP connection.
So I would appreciate that if request_cb can returns Some Response.t and can choice establish or close a connection.
Thanks
Maybe we should keep this part of the API compatible with the lwt counterpart, which uses a callback of this type: ?check_request:(Cohttp.Request.t -> bool)
and provides a secure default which checks the origin header against the host header to prevent cross-origin requests (https://github.com/vbmithr/ocaml-websocket/blob/master/lib/websocket_lwt.mli#L51).
Yes, I agree interfaces should be the same. @kkazuo needs to close the connection upon some events though, and this use-case does not look too absurd. What do you think about adding this to the Lwt backend (a way to close the connection) then making the two APIs identical?
Yes. It is essence whether to close or not. A boolean value is sufficient, but I want to perform computations to check access rights. So It would be like:
?check_request:(Cohttp.Request.t -> bool Deferred.t)
?check_request:(Cohttp.Request.t -> bool Deferred.t)
That looks like a reasonable choice to me.
Fixed via 387d9b025333af04ae52b358e6524848d56fa91a.
How can I get HTTP header info (like HTTP request path, Websocket Subprotocols, Websocket Extensions) ?