Hacker News Reader

Comment by im_down_w_otp | Hacker News Reader

Isn't the point of an HTTP caching proxy, in-part, to mitigate that exact problem?

Doesn't really work if the upstream is https, unless you MITM all your proxy users.

You can architect for this though. Let's say you're a data-heavy SaaS selling primarily to enterprise, which operates their own datacenters. Instead of naively forcing all requests to go first to api.saas.example, you allow the enterprise to configure its account to first hit a cache service (that you write and distribute) located at saas-cache.enterprise.internal, allowing both the SaaS and the enterprise to save on bandwidth by not fetching the same data 20 times over.

Seems like a more common approach would be for the customer to use the on-premise version of the software in question.

Edge caching is not MITM and it's not helpful to pretend that it is.

MITM is a form of attack. Edge caching is simply a form of distributed architecture.

The typical objection to edge caching HTTPS is that it requires giving your private key to a 3rd party. Well if you're hosting in the cloud, who do you think has your private key at the origin?

The comment I replied to didn't say edge caching or reverse proxy - it said http caching.

An edge/reverse proxy on the SaaS network doesn't solve 20 workstations in an office making requests over the internet to retrieve the same resource.

A regular http proxy in that office does prevent 20 internet requests but it requires MITM for https to work.

The point of a cloud to let you host servers nearby

It is? Physical location is pretty far down my list of reasons I use cloud providers. Certainly, API-driven resource provisioning is way higher, as is pay-for-what-you-use costing.

Reply on news.ycombinator.com