Expose 'local()' method to allow request content to be accessed in fairing

[martynp]

Work-in-progress to expose "local()" method in Request module to enable body content to be pre-processed.

[martynp]

#2576

[martynp]

Example use case here:

https://github.com/martynp/rocket_hmac

If acceptable I will work up some documentation etc. for the local method

[SergioBenitez]

I don't think we should expose this. It encourages reading the request body data into memory, which is not something I'd like to do. Unless there's a significantly motivated reason to do this, I think we should find a better API which encourages a pass-through stream of the data.

For example, in your project, the ideal seems to be the ability to do something like the following given some &mut Data:

data.adapt_fold(|req| Hasher::new(), |hasher, req, chunk: &[u8]| hasher.hash(chunk), |req, n, hasher| {
    req.local_cache(|| Hash(hasher.finish()));
});

I think what we want is something functionally equivalent to the following trait:

trait DataAdapter {
    async fn adapt<'r, S: Stream<Item = Cow<'r, [u8]>>>(
        &mut self,
        req: &Request<'_>,
        stream: S
    ) -> impl Stream<Item = Cow<'r, [u8]>>;

    async fn finish(&mut self, n: N, req: &Request<'_>);
}

And then we can write helpers like the adapt_fold above. This allows streams to be adapted endlessly. IE, you could call data.adapt(adapter1).adapt(adapter2).adapt(adapter3) and so on. It also allows us to use all of the existing functionality for streams.

A similar API would be to instead pass in an AsyncRead and expect another AsyncRead. In either case, both of these APIs encourage streaming the data, perhaps the former more so. It does not seem particularly straightforward to implement such an API, however, but I'd be in favor of adding such functionality.

[martynp]

Thanks for the feedback!

With the AsyncRead option would that sit in the vicinity of the open method in the Data module?

Given this is in the request, I assume this should not have the ability to mutate data in the steam?

I can see it would be a bit difficult to implement - I have used simple adaptors before for reading compresses & encrypted files, but always as separate entities implementing the much simpler std::io::read trait.

I will have a tinker.

[SergioBenitez]

Yes that's right. I've implemented a draft of the idea. I can post it here for you later today, and perhaps you can test it out and take it across the finish line. How's that sound?

[martynp]

That would be great, I definitely will look at it and do the docs etc.

[SergioBenitez]

See #775 (comment).