# HTTP Cache-Control Quirks, Trailers, and Other Surprising Standard Behaviors

DevFeed: [HTTP Cache-Control Quirks, Trailers, and Other Surprising Standard Behaviors](<https://devfeed.tech/articles/httpwtf-19073.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/http-wtf/>)

Author: HTTP Toolkit; Tim Perry

Published: 2021-03-04T15:00:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [browser](<https://devfeed.tech/topics/browser.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [cache](<https://devfeed.tech/tags/cache.md>), [caching](<https://devfeed.tech/tags/caching.md>), [http](<https://devfeed.tech/tags/http.md>), [request](<https://devfeed.tech/tags/request.md>), [responses](<https://devfeed.tech/tags/responses.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

An exploration of surprising HTTP behaviors, including how no-cache and private still allow caching, when to use no-store, and how HTTP trailers append metadata after the message body.

## Source excerpt

HTTP is fundamental to modern development, from frontend to backend to mobile. But like any widespread mature standard, it's got some funky skeletons in the closet. Some of these skeletons are little-known but genuinely useful features, some of them are legacy oddities relied on by billions of connections daily, and some of them really shouldn't exist at all. Let's look behind the curtain: No-cache means "do cache" Caching has never been easy, but HTTP cache headers can be particularly confusing. The worst examples of this are no-cache and private. What does the below response header do? Cache-Control: private, no-cache It looks like this means "don't store this response anywhere", right? Hahaha no. In reality, this means "please store this response in all browser caches, but revalidate it when using it". In fact, this makes responses more cacheable, because this applies even to responses that wouldn't normally be cacheable by default. Specifically, no-cache means that your content is explicitly cacheable, but whenever a browser or CDN wants to use it, they should send a request using If-Match or If-Modified-Since to ask the server whether the cache is still up to date first. Meanwhile private means that this content is cacheable, but only in end-client browsers, not CDNs or proxies. If you were trying to disable caching because the response contains security or privacy sensitive data that shouldn't be stored elsewhere, you're now in big trouble. In reality, you probably wanted no-store. If you send a response including a Cache-Control: no-store header, nobody will ever cache the response, and it'll come fresh from the server every time. The only edge case is if you send that when a client already has a cached response, which this won't remove. If you want to do that and clear existing caches too, add max-age=0. Twitter notably hit this issue. They used Pragma: no-cache (a legacy version of the same header) when they should have used Cache-Control: no-store, and acc