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

Re: Hit-metering: to Proposed Standard?

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 20 Nov 96 14:43:09 PST
Message-Id: <9611202243.AA00164@acetes.pa.dec.com>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1928
    Connection cannot be used as a means for two caches to communicate
    because not all proxies have caches.  Requiring that a non-cache
    proxy fiddle with Cache-Control on the basis of what they must drop
    from Connection is just not appropriate.  Use a design which
    doesn't fail through such proxies.

It is certainly true that our proposal does not provide hit-metering
through non-caching proxies.  It may be possible to extend it in
such a way that it does so, and I will think about whether this is
feasible.  In fact, it may be possible to do this without changing the
specification of the headers in our proposal, but rather only changing
the rules for interpreting them.

However, we believe that, in order for origin servers to be willing
to using hit-metering instead of cache-busting, that they need to
have very strong assurances that if a proxy appears to offer to
hit-meter, then it will in fact do so.  We do not believe that a
system based on Cache-control can do this, unless it is made mandatory
for all HTTP/1.1 implementations ... and we did not expect this to
be politically feasible (or even to be wise).

So we settled for a mechanism that "fails conservatively"; i.e., if
there is a non-metering proxy in the path, then the rest of the
distribution path reverts to using "proxy-revalidate" in those cases
where the origin server wants to see a hit-count.

When you say something is "just not appropriate", it might be useful
to provide a specific example of what could go wrong.

    In addition, the current design, if implemented, forces the proxy to add
	Connection: Meter
	Meter: will-report-and-limit
    (or "wont-report" or "wont-limit") to every single request forwarded,
    regardless of the likelihood that the origin server and the requested
    resource happen to use hit-metering.

You apparently failed to read the part that says:

   By definition, an empty Meter header:


   is equivalent to "Meter: will-report-and-limit", and so, by the
   definition of the Connection header (see section 14.10 of the
   HTTP/1.1 specification [1]), a request that contains

       Connection: Meter

   and no explicit Meter header is equivalent to a request that contains

       Connection: Meter
       Meter: will-report-and-limit

   This makes the default case more efficient.

In other words, we do expect to see 14 extra bytes per connection
(not per request!) as a consequence of this proposal.  We regard
this as a reasonable tradeoff for not insisting that Meter support
be mandatory in HTTP/1.1 (as I said, we didn't think this would be
a good idea), and a very reasonable tradeoff if it averts just
1 request out of 20*N, where N is the mean number of requests
per connection (since the average request seems to involve
around 300 bytes of headers these days, and I'm not even counting
the averted bytes for 304 responses).

And remember that if you don't want to use your inbound bandwidth
for this, you don't have to send it.  Period.

    I do not believe that the proposal is valuable to the Internet
    community.  In fact, I believe it will cause more harm than good if
    implemented, and would strongly recommend not implementing it as it
    currently stands.  On that basis, I oppose it going forward as a
    Proposed Standard.

The only "harm" that you described in your message was the sending
of the 14 extra bytes per connection, based on your (unsupported)
estimate that most resources would not be hit-metered.  If this is
the only specific harm that you can point to, maybe we should be
adopting Paul Leach's proposal for header abbreviations.

Received on Wednesday, 20 November 1996 15:17:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC