Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Access to underlying file descriptors? #65

Closed
anmonteiro opened this issue Aug 9, 2018 · 3 comments
Closed

Access to underlying file descriptors? #65

anmonteiro opened this issue Aug 9, 2018 · 3 comments

Comments

@anmonteiro
Copy link
Contributor

I'm trying to upgrade an incoming request to a Websocket connection. Even though I'm able to upgrade the connection and send a response, it seems that for fixed length requests, httpaf closes the request body immediately, meaning that any more incoming data from the client is discarded.

I'm looking for another way to set this up, but I need your help:

  1. Could I somehow tell httpaf to keep the request body open, or re-open it myself?
  2. I would rather use the public httpaf API, but if the above is not possible, is there an escape hatch to get access to the underlying unix file descriptors? I've looked around a bit and it seems this is not possible?

Is there something else I should be doing that I'm missing?
anmonteiro referenced this issue in anmonteiro/httpun Nov 17, 2018
@anmonteiro
Make wait_for_first_flush configurable in streaming responses
be0734e 
This is related to #65. I managed to get websockets working using
Conduit in order to gain access to the file descriptors. However,
because streaming responses wait for the first write to flush response
bodies, I could never deliver the connection upgrade with 1. an empty
response body and 2. while not closing the writer.

Making `wait_for_first_flush` configurable (which I see was already in
the roadmap) solves this problem.

I've tested this in my code and it's working really well now. Please
let me know if you had thought of another way of configuring this
behavior.
anmonteiro referenced this issue in anmonteiro/httpun Dec 14, 2018
@anmonteiro
Expose the underlying file descriptors
be929e4 
This is a proposal to fix #65. Access to the underlying file descriptors
is (from what I gather) necessary to make use of a websocket connection.
This proposal adds a new function, `Reqd.descriptor`, that returns the
underlying file descriptor.
@seliopou
Copy link
Member

The best way to do this would be to modify the async and LWT runtimes. It could maybe made easier by adding something like Reqd.respond_with_upgrade which would result in another write state for the state machine, which would clearly signal to the runtime what needs to happen, i.e., pass the fd to a function that will handle the upgraded connection.

I know there's a way to do this even without that change, but it escapes me at the moment.

@aantron
Copy link
Contributor

aantron commented Jan 12, 2019

@seliopou, by the Async and Lwt runtimes, do you mean Httpaf_async and Httpaf_lwt, or Async and Lwt themselves? I suppose the former..

@seliopou
Copy link
Member

The former.

anmonteiro added a commit to anmonteiro/httpun that referenced this issue Jan 17, 2019
@anmonteiro
Add Reqd.respond_with_upgrade and upgrade handler
e78ca90 
This diff implements the suggestion given in
inhabitedtype/httpaf#65 (comment)
and adds a `Reqd.respond_with_upgrade` function, along with an upgrade
handler to which the Async / Lwt runtimes can pass a file descriptor
for applications to handle switching the protocol.
anmonteiro added a commit to anmonteiro/httpun that referenced this issue Apr 23, 2019
@anmonteiro
Add Reqd.respond_with_upgrade and upgrade handler
164e25d 
This diff implements the suggestion given in
inhabitedtype/httpaf#65 (comment)
and adds a `Reqd.respond_with_upgrade` function, along with an upgrade
handler to which the Async / Lwt runtimes can pass a file descriptor
for applications to handle switching the protocol.
Lupus pushed a commit to Lupus/httpaf that referenced this issue Dec 8, 2020
@anmonteiro
Pass alpn_protocols to the gluten_lwt_unix runtime (inhabitedtype#65)
fbca566
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@seliopou @anmonteiro @aantron