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.

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 server: propagate extensions in http response #1514

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

niklasad1
Copy link
Member

@niklasad1 niklasad1 commented Jan 8, 2025

Close #1509

This PR propagates the extensions set by the RPC middleware such that users can inspect them via HTTP middleware and perhaps indicate a HTTP error or something.

The handling of batch requests are not ideal because because the if the same type is used more than once then the
most recent wins in the old data is overwritten. Because the http::Extensions works based on the rust type ids and it's not possible to merge two types in a clean way I think i.e, just overwrite them with the most recent one...

I had in mind that the user could inject a Vec or another collection that each call RPC call/request can push to it but we can't do that internally in jsonrpsee without some hacks like merging the rust collection types ourselves such as Vec<String>, Vec<usize> and so on...

For now, I don't have a good solution except make user responsible to "inject unique types" because it may be overwritten in a batch but annoying....

We could introduce another representation of the extensions internally and just merge them before constructing the response though...

@niklasad1 niklasad1 marked this pull request as ready for review January 9, 2025 16:09
@niklasad1 niklasad1 requested a review from a team as a code owner January 9, 2025 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pass response contexts from RPC middleware to HTTP middleware
1 participant