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

Keeping the state across request in fairing #581

Closed
idubrov opened this issue Mar 6, 2018 · 2 comments
Closed

Keeping the state across request in fairing #581

idubrov opened this issue Mar 6, 2018 · 2 comments
Labels
question A question (converts to discussion)

Comments

@idubrov
Copy link

idubrov commented Mar 6, 2018

We have a simple fairing doing time measurements for the request. What we do is we capture "start" time in the on_request handler and measure elapsed time in the on_response handler.

Unfortunately, it seems like there are not a lot of options to save that "start" timestamp. One can add a header to the request and check it later in the response, but that requires converting timestamp into a string (and it seems std::time::Instant is not friendly to to_string/parse). Also, that opens a potential attack as headers are partially under the control of the caller (you have to be careful to use replace_header versus add_header).

Other option would be to use thread-local, which is probably going to work, but can we rely that on_response would be called on the same thread? I think, we can, but documentation does not mention that explicitly.

Or maybe keep our own hash map, but then we need a way to identify a request and also to make sure that we clean that map no matter what (like, request catastrophically fails that on_response is never called).

  1. The version of Rocket this question is based on, if any.

0.3.6

  1. What steps you've taken to answer the question yourself.

Searched issues, looked at the Request API, looked at the fairings API

  1. What documentation you believe should include an answer to this question.

Fairing documentation should mention thread local as an option (if that is an option). Also, having an example that measures the processing time would be helpful (versus an example that only counts requests) -- this is probably very common use-case.

@berkus
Copy link

berkus commented Apr 9, 2018

Related #461

@SergioBenitez
Copy link
Member

This is now easily possible with request-local state (#654), implemented in 97c6b3a.

@SergioBenitez SergioBenitez added the question A question (converts to discussion) label Jul 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question A question (converts to discussion)
Projects
None yet
Development

No branches or pull requests

3 participants