- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 29 Sep 2014 19:23:07 +1300
- To: ietf-http-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/09/2014 5:16 p.m., Matthew Kerwin wrote: > On 29 September 2014 13:54, Sandro Hawke wrote: > >> On 09/28/2014 07:13 PM, Matthew Kerwin wrote: >> >> >> ​If it's 200 you have to be careful to set the cache control >> headers etc. so that intermediate caches don't screw things up. >> >> >> It sounds like you don't trust the Vary: Prefer to do its job. >> Are you just being cautious, or is there reason to think Vary >> doesn't actually work (or perhaps that I'm misunderstanding what >> it does). ​ ​ >> > > I'm not entirely trusting, no. It might be paranoia, but it might > also come from random interactions with HTTP/1.0 proxies in the > wild. I still send Pragma headers, too. :\ > > <snip> > > >> Yes, there's a lot to be said for this design (sending 303 and a >> body), if it would work. I only have it second hand that it >> doesn't work, so I don't even know the original source of my >> claim that it doesn't. >> >> > That's definitely the crux, then. Whichever failure mode is more > likely (poisoning caches in spite of Vary, vs. stripping body of > 303) is the one that should be handled by default. I'd be doing a > survey here, and some field tests, to inform the decision. > 303 status is and always has been clearly defined as having a payload. It is also a common redirect used in captive portals for delivery with session initiation pages. Any middleware stripping those is breaking HTTP and well deserving of bug reports. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKPrJAAoJELJo5wb/XPRjVasIAMfQb3C2XkvWxgc8NF6xOhlA JSzsZvg5vgZdfSgevAidZSlKzC04QUHxNowpAcIze4RPMCO7e9YLLl/hUNyS9n3/ /3lT2krQWheuTc+VIQt9DgVka2cuA3h4BM1QZhksqed/xwSgtcGlSA3R+BzRjLvE rkKD/ac4es2RVuUWlJLjL4hAh18FGyvko/gRegjj6vUkqxySJnmL+1XlmDWM1EKs 3WO2+khofQScWUFya/t9qdekdy0W5dNzl7pGlBS+wRm1W/aLIjshBZue7ra8uoC4 3z/C/bfzu6LxWhPQkM5e0cGrflaulLB+zJza4vGeAugrtnlx47DUCPGyEy+QMvU= =NP/p -----END PGP SIGNATURE-----
Received on Monday, 29 September 2014 06:23:42 UTC