jhttp: Re-work the Bridge interface to require less plumbing. #52
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The purpose of a jhttp.Bridge is to convey requests from an HTTP handler into a JSON-RPC server. The way I had implemented it, however, required interposing a client, which complicated the logic of forwarding. Instead of requiring a client, the Bridge now takes an unstarted server, and starts it up on an in-memory channel. We still have to parse the requests to detect whether there are any calls, since HTTP requires a response regardless of whether the JSON-RPC server replies, but we no longer need to virtualize request IDs or re-marshal the request values. This is a breaking change to the Bridge API.
Allow the owner of the bridge to override the content type check.
creachadair
added a commit
that referenced
this pull request
Sep 12, 2021
Since #52 was merged, this method is no longer used.
creachadair
added a commit
that referenced
this pull request
Sep 27, 2021
creachadair
added a commit
that referenced
this pull request
Sep 27, 2021
This commit approximately reverts the interface changes to the HTTP Bridge merged with #52. While those changes did simplify the implementation, they did so at the cost of usability: Unvirtualized request IDs make it hard for clients to avoid ID collisions, and the low-level channel interface made it impossible for the client to access the HTTP request context for authentication. While this is yet another breaking change to the Bridge interface, it fixes the problems mentioned in #57, and the resulting interface is a little cleaner. The main changes here are: * Update the Bridge API to allow both client and server to be configured. * Restore ID virtualization. * Restore the SetID method to *Response. * Restore and update the tests. * Restore and improve the HTTP example code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change is in support of #46. It is a breaking change to the jhttp.Bridge API.
The purpose of a jhttp.Bridge is to convey requests from an HTTP handler into a
JSON-RPC server. The way I had implemented it, however, required interposing a
client, which complicated the logic of forwarding.
Instead of requiring a client, the Bridge now takes an unstarted server, and
starts it up on an in-memory channel. We still have to parse the requests to
detect whether there are any calls, since HTTP requires a response regardless
of whether the JSON-RPC server replies, but we no longer need to virtualize
request IDs or re-marshal the request values.