4 ms·

We talked about this during the outage before but any API requests related to account information should not be going through a cacheable CDN. At the mild end,

We talked about this during the outage before but any API requests related to account information should not be going through a cacheable CDN. At the mild end, you could get stale data. Deposit some money and the cache doesn't reflect making you wonder whether the deposit happened or not. On the worst end, you get this - all users get exposed the most recently requested data. All this to save... a few kB?

dijit 5y ago
I agree. I've run some eCommerce sites before, we were PCI Tier 1, roughly 1% of web traffic: but nowhere _near_ the level of security Klarna should have; we had the CDN's activated only on subdomains... always. Usually static.<site>.com or whatever.. This has the added benefit of not sending cookies to the CDN, because that can affect latency and is also a bit less secure because a static image/css/js does not need the cookie. (and bandwidth, before we were charged per byte (and that's egress now anyway in most cases, god I'm old.)). If I had to venture a guess, they're probably scared of getting slammed with a DDoS so they "guard" everything behind the CDN, it's not about caching. We got slammed with DDoS's too so we had to have systems in place to push BGP routes via verisign to "scrub" the traffic... we didn't even have that many "credits" and it cost millions...
johbjo 5y ago
I suspect the background is the app is showing html-views rendered on the server, and they are sharing as much infrastructure as possible. To make it easier on the app team. If they separated app/cdn/web with different SSL certificates, something like this wouldn't be possible even when developers eff up.
glenngillen 5y ago
Whether a CDN is caching or not could itself just be a misconfiguration. Passing dynamic non-cached requests through a CDN isn’t about saving a few kB for the server (by definition it still has to generate it). It’s about improving end-user performance through things like having edge termination of TLS. So it’s not so easy to have such a blanket statement as no API requests should go through a CDN. While it’s all too easy to inadvertently turn on the caching of requests.
- Cthulhu_ 5y ago
  And CDN's offer flood / ddos protection as well.
- ownagefool 5y ago
  > It’s about improving end-user performance through things like having edge termination of TLS. Err, wouldn't the CDN itself still need to do the same TLS handsake with the end server?
  - tailspin2019 5y ago
    In my case I use Cloudflare Tunnel [0] which is an actual agent installed on my web servers that creates a reverse tunnel back to Cloudflare's network. This creates a complete disconnection between whatever TLS handshakes are happening between the client and my CDN (Cloudflare) and whatever's going on locally between the tunnel daemon and my local web server process. For example you can choose to run these tunnels without HTTPS at all on your local webserver (bearing in mind that you have no inbound firewall ports open to the webserver box - no traffic leaves that box unencrypted), the daemon directly proxies your local-only HTTP port on the machine over an encrypted tunnel to Cloudflare and via whatever flavour of Cloudflare TLS you like to your end-users. [0] https://www.cloudflare.com/en-gb/products/tunnel/ https://www.cloudflare.com/en-gb/products/tunnel/
  - q3k 5y ago
    Most CDNs out there maintain a pool of HTTPS keep-alive'd connections to backing services. This eliminates the roundtrip needed for establishing a TCP connection and the roundtrip (or two) needed for setting up TLS. Another reason a no-caching CDN can help is when that CDN has a higher quality connection to the backing service than the user has. A lot of eyeball networks out there might have terrible transit connectivity to the global Internet during peak hours (because that cost money), but generally have high quality settlement-free peering with CDNs. By paying a CDN, you're effectively paying them to provide better Internet connectivity to your users.
    - nrmitchi 5y ago
notyourday 5y ago
> We talked about this during the outage before but any API requests related to account information should not be going through a cacheable CDN. That is simply not correct. The entire reason why Fastly is so popular is because it lets you cache the API using cache-bust on write. Between the request collapsing, shielding, and a near immediate cache invalidation caching API allows one to accept enormous spikes of traffic that normally would bring down the origins.

dijit 5y ago

I agree. I've run some eCommerce sites before, we were PCI Tier 1, roughly 1% of web traffic: but nowhere _near_ the level of security Klarna should have; we had the CDN's activated only on subdomains... always. Usually static.<site>.com or whatever.. This has the added benefit of not sending cookies to the CDN, because that can affect latency and is also a bit less secure because a static image/css/js does not need the cookie. (and bandwidth, before we were charged per byte (and that's egress now anyway in most cases, god I'm old.)). If I had to venture a guess, they're probably scared of getting slammed with a DDoS so they "guard" everything behind the CDN, it's not about caching. We got slammed with DDoS's too so we had to have systems in place to push BGP routes via verisign to "scrub" the traffic... we didn't even have that many "credits" and it cost millions...

johbjo 5y ago

I suspect the background is the app is showing html-views rendered on the server, and they are sharing as much infrastructure as possible. To make it easier on the app team. If they separated app/cdn/web with different SSL certificates, something like this wouldn't be possible even when developers eff up.

glenngillen 5y ago

Whether a CDN is caching or not could itself just be a misconfiguration. Passing dynamic non-cached requests through a CDN isn’t about saving a few kB for the server (by definition it still has to generate it). It’s about improving end-user performance through things like having edge termination of TLS. So it’s not so easy to have such a blanket statement as no API requests should go through a CDN. While it’s all too easy to inadvertently turn on the caching of requests.

Cthulhu_ 5y ago
And CDN's offer flood / ddos protection as well.
ownagefool 5y ago
> It’s about improving end-user performance through things like having edge termination of TLS. Err, wouldn't the CDN itself still need to do the same TLS handsake with the end server?
- tailspin2019 5y ago
  In my case I use Cloudflare Tunnel [0] which is an actual agent installed on my web servers that creates a reverse tunnel back to Cloudflare's network. This creates a complete disconnection between whatever TLS handshakes are happening between the client and my CDN (Cloudflare) and whatever's going on locally between the tunnel daemon and my local web server process. For example you can choose to run these tunnels without HTTPS at all on your local webserver (bearing in mind that you have no inbound firewall ports open to the webserver box - no traffic leaves that box unencrypted), the daemon directly proxies your local-only HTTP port on the machine over an encrypted tunnel to Cloudflare and via whatever flavour of Cloudflare TLS you like to your end-users. [0] https://www.cloudflare.com/en-gb/products/tunnel/ https://www.cloudflare.com/en-gb/products/tunnel/
- q3k 5y ago
  Most CDNs out there maintain a pool of HTTPS keep-alive'd connections to backing services. This eliminates the roundtrip needed for establishing a TCP connection and the roundtrip (or two) needed for setting up TLS. Another reason a no-caching CDN can help is when that CDN has a higher quality connection to the backing service than the user has. A lot of eyeball networks out there might have terrible transit connectivity to the global Internet during peak hours (because that cost money), but generally have high quality settlement-free peering with CDNs. By paying a CDN, you're effectively paying them to provide better Internet connectivity to your users.
  - nrmitchi 5y ago

notyourday 5y ago

> We talked about this during the outage before but any API requests related to account information should not be going through a cacheable CDN. That is simply not correct. The entire reason why Fastly is so popular is because it lets you cache the API using cache-bust on write. Between the request collapsing, shielding, and a near immediate cache invalidation caching API allows one to accept enormous spikes of traffic that normally would bring down the origins.