[8646] in www-talk@info.cern.ch
Re: 3 Proposals: session ID, business-card auth, customer auth
daemon@ATHENA.MIT.EDU (Brian Behlendorf)
Tue Jul 18 18:47:04 1995
Date: Tue, 18 Jul 1995 15:36:52 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>
Reply-To: Brian Behlendorf <brian@organic.com>
To: James Gosling <jag@scndprsn.eng.sun.com>
Cc: connolly@beach.w3.org, tmyerson@iserver.interse.com, www-talk@w3.org
In-Reply-To: <9507182040.AA09151@norquay.Eng.Sun.COM>
Resent-From: www-talk@www10.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/
