- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 15 Aug 2016 10:23:08 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Adrien, On Fri, Aug 12, 2016 at 01:32:03AM +0000, Adrien de Croy wrote: > if the request was non-conditional, that would also happen if you didn't > have any version already. Client basically needs to retry. > > FWIW we see this happen quite a bit with proxies encountering broken > servers. > > E.g. > > 1. client makes non-conditional request to proxy. > 2. Proxy has a stale version > 3. Proxy adds If-None-Match and stored ETag > 4. Server responds with 304 with different ETag (yes, there are several > high-profile servers that frequently do this) > 5. Exasperated proxy forwards 304 to the client, which then has to retry, > hopefully the proxy removed the invalidated (by ETag) cache entry in the > meantime so it works the second time. A long time ago (~15 years) I've been experiencing a different case where a caching proxy would ignore the if-none-match field, pass the request to the server, which responds 304, which is forwarded to the client and cached by the proxy. The next client requesting the same object to the proxy would be delivered the 304 from the cache. Willy
Received on Monday, 15 August 2016 08:23:48 UTC