/me nods We'll still need to fix the processing so we don't respond with 304s to the client and deal with the situation where we get a 304 and the cache entry is invalidated below us -- again that's follow on work.
So let's go ahead and commit this then.. On Tue, Jun 8, 2010 at 6:05 AM, John Hjelmstad <[email protected]> wrote: > Yes... but it's also orthogonal IMO. > > The point here is that, regardless the fetcher's behavior, we shouldn't > cache a 304 -- there's no guarantee that the Shindig fetcher's behavior is > tied to the original request (esp. request headers such as If-None-Match et > al). Stated another way, this is Shindig-as-fetcher-to-site rather than > client-as-fetcher-to-Shindig. > > Etag support lives more on the "front end" of the proxying pipeline, > utilizing state that's under the control of the shindig back-end. > > --j > > On Tue, Jun 8, 2010 at 5:47 PM, <[email protected]> wrote: > >> seems fine for a first cut. I assume the etag etal support comes >> later... >> >> >> >> http://codereview.appspot.com/1605041/show >> > >
