Sounds good re: committing this. Re: the remainder, I believe I agree but if I'm not mistaken the underlying issue is whether we want to support being a "full" HTTP client in the ETags/If-Modified-Since/etc sense. The issue that gave rise to this behavior is that an HttpFetcher was modified to include such behavior. Without them, we won't get 304s in the first place. Should we support this in a more explicit way?
Let me know if I'm missing the motivation behind the use cases you describe. Cheers, --j On Tue, Jun 8, 2010 at 5:15 PM, Paul Lindner <[email protected]> wrote: > /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 >>> >> >> >
