- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 4 Nov 2020 17:47:00 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Roberto Polli <robipolli@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Nov 04, 2020 at 04:14:41PM +0000, Poul-Henning Kamp wrote: > -------- > Julian Reschke writes: > > Am 04.11.2020 um 16:12 schrieb Roberto Polli: > > > Hi Julian, > > > > > > Il giorno mer 4 nov 2020 alle ore 15:22 Julian Reschke > > > <julian.reschke@gmx.de> ha scritto: > > >> ... we essentially want to define something that is > > >> the same as POST, with the additional property of being safe by > > >> definition. Nothing more specific than that. > > > > > > Q: POST is cacheable (under conditions). I was curious why SEARCH is > > > not cacheable: this can be useful... > > > > Cacheability is an open TODO. I agree that it's supposed to be at least > > as cacheable as POST :-). > > Please specify that SEARCH results must *always* have a Cache-Control. Or better, that cacheable results must have it. The rationale here is that as usual, all those who don't care will forget to put it and will have their search working fine, and things will break when inserting a cache. Usual stuff "your reverse-proxy doesn't support my server". Better be clear from the start that it's OK not to have the header but then one must not expect caching. Because you'll have to deal with it anyway. Willy
Received on Wednesday, 4 November 2020 16:50:30 UTC