<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>HTTP Caching on Nalar</title>
    <link>https://nalar.dev/tags/http-caching/</link>
    <description>Recent content in HTTP Caching on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/http-caching/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Design Shared Cache Keys Around Response Variance</title>
      <link>https://nalar.dev/design-shared-cache-keys-around-response-variance/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/design-shared-cache-keys-around-response-variance/</guid>
      <description>&lt;p&gt;Shared HTTP caches can reduce latency and origin load, but they also introduce a security boundary. A cache stores a response produced for one request and may later serve that response to another request. That reuse is correct only when both requests are equivalent for every property that can affect the response.&lt;/p&gt;&#xA;&lt;p&gt;A dangerous configuration appears when an origin varies its response on a request property that the shared cache does not include in cache selection. An attacker can send a crafted request, cause the origin to generate attacker-influenced content, and leave that content stored under a key that ordinary visitors also use.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
