- From: Adrien W. de Croy <adrien@qbik.com>
- Date: Mon, 18 Mar 2013 12:19:17 +0000
- To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
- Cc: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
------ Original Message ------ From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Adrien W. de Croy" <adrien@qbik.com> Cc: "Amos Jeffries" <squid3@treenet.co.nz>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org> Sent: 19/03/2013 1:05:11 a.m. Subject: Re: WGLC p6 4.2.1 >In message <em94119d23-43b0-4de4-a3e3-8c30e8a40bfc@bombed>, "Adrien W. >de Croy" writes: > >>>>for instance a cache receiving a request with If-Modified-Since >>>>later >>>>than its own Last-Modified, may presume the client has a later >>>>copy,=20 >>>>and >>>>discard its own copy. >>> >>>Uhm, so you're saying I can clean the entire cache with bogos IMS >>>requests ? >> >>that's not the point. > >It very much is: A cache would have to be stupid to make that >assumption, and we should not be protecting stupid mistakes with >the specification, we should make things work. it was just one example. There are potentially limitless ones. fundamentally, we're changing the semantics. Do we even know what that may break? I don't recall seeing a discussion about it on list, but maybe it was discussed in a meeting. > >No matter what you write in the specification, you will have IMS >headers with non-server-supplied timestamps, because it is possible >and there are legitimate use-cases. I agree it's possible, I'm not sure about the use-cases. at least not the one you mentioned before. Sending If-Modified-Since currently indicates you have a copy. So we're looking to break that too? A cache needs to know which version is being re-validated, whether its own or the clients. It's probably not a train wreck, but it's convoluted enough trying to figure out what on earth is going on when you get a 304 back and you were checking multiple items, some with ETag some with IMS. I never got a straight answer on my query about whether it's valid to send a 304 back to a request that contained If-None-Match with a different ETag. Personally I consider that a server bug as well. > >We can discuss if the text expresses this optimally, but there is >no way the text can put this particular genie back in his bottle. I think we will need to make further changes, to refer to these changes elsewhere in the spec, e.g. where it's discussed that to make a conditional request one adds If-Modified-Since using the content of a previous Last-Modified response header. > >-- >Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >phk@FreeBSD.ORG | TCP/IP since RFC 956 >FreeBSD committer | BSD since 4.3-tahoe >Never attribute to malice what can adequately be explained by >incompetence. >
Received on Monday, 18 March 2013 12:19:41 UTC