-
Notifications
You must be signed in to change notification settings - Fork 237
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.
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
http async replies, upgrade hook #324
base: public
Are you sure you want to change the base?
Conversation
If the headersComplete callback returns 'upgrade', return from the server callback immediately rather than continuing to the prepareResponse callback.
websockets.js doesn't check socket.write() to see how much data it can send. The agoric pixel demo goes over 1k, so let's use 4k for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure about the goal of this change. It looks like it intentionally stalls-out the HTTP request after all the request headers have been received. How is that useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By deign, the HTTP implementation does not use promises. We'll need to find another solution to the need this is addressing.
As noted in #308, to upgrade an http server to websockets.
I think I was also emulating the node http API, where replies can be computed asynchronously. Can you elaborate? What design constraint conflicts with the use of promises? I can see a number of outcomes here:
|
I saw the note in #308 that the change is to support websocket upgrades. There is more going on which is not visible from the change. How does the proposed change support the websocket case you outline? Regarding HTTP, the design constraint is specifically to not use Promises to eliminate unneeded overhead. Consequently, the PR cannot be accepted. The potential solutions you enumerate above are: accept changes inconsistent with the implementation, fork, or change your goals. That overlooks my preferred solution - establish the requirements clearly, then design and implement a solution. Happy to work with you on that. |
Oops; of course; I left the best outcome out. rephrase: It's been a while since I knew exactly why I (thought I) needed this. I hope I can explain it better in due course, but other work seems to have higher priority these days; I can double-check. |
fixes #308
doesn't fix #313 but works around it to some extent