W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

Re: Hit-metering: to Proposed Standard?

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 26 Nov 96 10:54:51 PST
Message-Id: <9611261854.AA06335@acetes.pa.dec.com>
To: hardie@nasa.gov
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1967
Sorry for the slow response ...

    > If someone is able to describe a specific scenario where the use
    > of the Meter mechanism, as proposed in our draft, does in fact provide
    > more per-client information than the existing HTTP/1.1 mechanisms,
    > then we would regard this as a bug in our specification that needs
    > to be fixed (or at least, that needs to be called out in the Security
    > Considerations section).
    The use of the Vary header in a do-report situation clearly
    provides more information than is currently the case where a proxy
    cache is being used.  Currently, if I employ a proxy-cache and it
    requests a resource on my behalf, the origin server gets the data
    on the proxy cache (the cache may report through some data on the
    origin requestor, but it doesn't have to).  If the origin server
    cache-busts, the proxy-cache must re-request the data every time,
    but the origin server gets the data on the proxy-cache every time.
    With your proposal, it could get aggregates of the data on the
    actual requestors.  This compromises privacy.

If you are comparing the "Meter: do-report" situation with the
one for a fully cachable response, then, yes, the origin server
does get more information.

However, if you would instead compare the "Meter: do-report" situation
with the "Cache-control: max-age, must-revalidate" situation THAT IS
then I do not believe it is possible for the origin server to obtain
more data using "Meter: do-report" than it could without it.

In fact, because the hit-metering mechanism *does* aggregate data
regarding multiple requests (and probably multiple clients), it actually
delivers *less* data to the origin server than would be the case if
the origin server did simple cache-busting.  I.e., the origin server
would see the count of the number of clients who preferred to see
their documents in Kurdish, but not the actual request headers.
I view this as a potential improvement for privacy (although any
actual improvement clearly depends on the goodwill of the origin server).

Note that this *reduction* in the data is precisely what Phill
Hallam-Baker does not like about our proposal.
You wrote: 
    Imagine for a moment that someone used a Vary: on the Host header
    with Meter.
and then followed that up with
    Of course the host header would tell you nothing about the user.
    Imagine some other header instead.
We did try to "imagine some other header", and could not find any
specific example of a request header (or any other piece of information)
that the Meter mechanism would allow the origin server to obtain
that was not otherwise obtainable using the features of HTTP/1.1.

Received on Tuesday, 26 November 1996 11:17:37 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC