Support http caching

[tschroed]

As a generic http proxy, it would be useful for Envoy to support http caching. It seems like this could probably implemented as a filter.

[ctrlrsf]

I agree! This would be a killer feature. Right now using an nginx proxy to cache some API calls.

[PiotrSikora]

Do we want to cache inside Envoy or "one RPC away"?

[tschroed]

Yes?

It would be nice to have an in-memory L1 for hot objects and larger out-of-process L2 for less-popular content. Obviously caching policy would need to be context dependent as it typically doesn't make sense to cache the result of API calls while user-facing web pages can be cached even an RPC away without imposing user-perceivable delay.

[mattklein123]

If we end up doing this, it should definitely be a filter. Also, I would like to investigate whether we can avoid reinventing the wheel and potentially use some existing caching library. At some point I think I looked into it and the actual caching portion of varnish is exposed as a library, but I can't remember now.

[josephjacks]

@mattklein123 Fastly's h2o is taking over a lot of the prior use around Varnish (except for caching which they still use Varnish for) and there is a library: https://github.com/h2o/h2o/labels/libh2o -- there may be some h2o overlap with Envoy but I do agree that reinventing wheel could be bad.

Also h2o/h2o#173 (comment)

[PiotrSikora]

@josephjacks like you said, Fastly is using h2o in front of Varnish (mostly for HTTP/2 and TLS termination), and (lib)h2o doesn't provide any support for caching (see: h2o/h2o#776), so using it wouldn't help us.

[jmarantz]

xrefing #3023 which is about auth-caching, but would potentially introduce a physical cache into Envoy (though the requirements on an auth-class may be different from those on an http-cache).

[toddmgreer]

I have a high-level proposal for an Envoy HTTP caching filter. It handles the full range of HTTP caching, including vary headers, conditionals, ranges, and validation, but delegates actual storage to a set of pluggable interface classes, to enable varied types of caching.

Please see https://docs.google.com/document/d/1WPuim_GzhfdsnIj_tf-fIeutK0jO4aVQfVrLJFoLN3g/view, and let me know what you think.

[htuch]

@toddmgreer can you share from your personal gmail? We recently changed our policy to disallow design proposal that need whitelist ACL to access (I was the terrible person who last tried to do this ;) ). See the second point under Communication at https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md.

[toddmgreer]

Fixed permissions--the link I previously sent out should now be working again: https://docs.google.com/document/d/1WPuim_GzhfdsnIj_tf-fIeutK0jO4aVQfVrLJFoLN3g/view. Sorry for the inconvenience.

…

On Sun, Feb 10, 2019 at 11:14 PM Todd Greer ***@***.***> wrote: I had it shared properly, but somehow messed it up when I enabled comments. I'll fix it when I get home. On Sun, Feb 10, 2019, 8:23 PM htuch ***@***.*** wrote: > @toddmgreer <https://github.com/toddmgreer> can you share from your > personal gmail? We recently changed our policy to disallow design proposal > that need whitelist ACL to access (I was the terrible person who last tried > to do this ;) ). See the second point under Communication at > https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#868 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AWILPSuel29xPEt-T-CwdRtQuRlRTXsdks5vMPBGgaJpZM4NMumB> > . >