- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 05 Sep 2014 09:47:53 +0200
- To: Sandro Hawke <sandro@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, Eric Prud'hommeaux <eric@w3.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014-09-05 05:18, Sandro Hawke wrote: > ... > See: http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00 > >> implies that we don't have a representation of A, but we know >> what you >> really wanted (better than you) so here is a representation of B. > > If I understand right, your "better than you" comment is about how there > might already be a cache of B, and with 2NN that cached copy wont be > used. I agree that's a weakness in this proposal, although in all the > scenarios I've seen discussed, it's unlikely B would be cached unless > the 2NN response to A also was, so this weakness wouldn't be observed in > practice. Why wouldn't the response to the redirect GET (303 -> 200) not be cached? >> Now, here's the problem: >> >> "It's a round trip short cut!" No, because it won't be cached. > > As above, in the scenarios we're looking at, it's unlikely B will be > cached unless the 2NN response for A is also. > >> 303 round trips to the same server are almost entirely free in HTTP/1.1 >> because of persistent connections, > > Free of connection setup overhead, but they still cost a second > round-trip delay. > > In LDP applications, these calls are more like RPC than like displaying > a web-page, so milliseconds might possibly count more than they do in > more common existing applications. > ... It that's the problem, have you considered to tweak 303 to actually return the representation of the "other" resource (using a new Prefer option?)? GET / HTTP/1.1 Prefer: contents-of-related HTTP/1.1 303 SEE OTHER Location: /other Preference-Applied: contents-of-related ... (representation of /other) ? Best regards, Julian
Received on Friday, 5 September 2014 07:48:32 UTC