- From: Brian Behlendorf <brian@organic.com>
- Date: Tue, 18 Jul 1995 15:36:52 -0700 (PDT)
- To: James Gosling <jag@scndprsn.eng.sun.com>
- Cc: connolly@beach.w3.org, tmyerson@iserver.interse.com, www-talk@w3.org
On Tue, 18 Jul 1995, James Gosling wrote: > > Hmmm... care to give some details about these "ideas coming down > > the pipe?" Here are my thoughts, after having surveyed this space > > for a while: > > > > > > ******* I. The Request-ID: header field: > > ******* II. The business-card authentication scheme > > The problem I have with many schemes like this (leaving the ethical > questions alone for now!) is that they don't work in the face of proxy > caching. Either the cache uses the fields as part of the "cache key", > dramatically reducing the hit rate, or it doesn't, defeating the > purpose of the extension: to get access information back to the > provider. Definitely don't use it as a cache key. I see two things happening: 1) The cache sends an If-Modified-Since request, *with* the Request-ID from the new request. Server returns a 304, and keeps the request-ID for more info. 2) The cache opts to not send an If-Modified-Since request, instead serving up files locally. This is due to a cache config setting to keep possibly stale documents around for a short time (not recommended but impossible to control) or an Expires: header on the content with a later date than the current one. In this case, it's true that the server does not get the Request-ID, but then the server would never see that access anyways. Both cases are just like the current situation when it comes to collecting information, so I don't see it as a problem. I believe Simon Spero suggested that there were mechanisms in HTTP-NG to relay this type of information at a later point in time back to the server. Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Received on Tuesday, 18 July 1995 18:39:10 UTC