Re: New document on "Simple hit-metering for HTTP"

>     HEAD is not a NOOP, OPTIONS is.  What is the rationale for
>     using HEAD to relay the final count instead of OPTIONS?
> 
> I guess I've never really understood what OPTIONS is supposed
> to do, nor does the existing spec language make it clear that
> this is allowed to carry the various request-headers that
> are needed to report use-counts broken down by, say, User-agent.

My inclination is not to disallow anything unless it is known to be
harmful, and I don't think that this usage of OPTIONS would be harmful.

> In any event, while HEAD is not a "no-op", section 9.1.1 says
> "the convention has been established that the GET and HEAD
> methods should never have the significance of taking an action other
> than retrieval."  So, from the point of view of the server's
> visible state, doing a HEAD is indeed a no-op.  It does imply
> that the server is going to access the meta-data of the resource
> (because the "metainformation contained in the HTTP headers in response
> to a HEAD request SHOULD be identical to the information sent in
> response to a GET request"), which does impose a cost on the server.
> But no more than if the server had to do a conditional GET.

Actually, what made me think of it was the fact that a HEAD request
is normally considered another "hit" on that resource, whereas an
OPTIONS request should not be (speaking with my wwwstat hat on).
That begs the question of whether the proxy or origin would reduce
the reported count by one to avoid improperly counting the last HEAD
action as a "hit"? Such a question is difficult to answer, since it
depends on how the server collects and analyzes such data.

> Finally, OPTIONS responses include messages bodies, and HEAD
> responses "MUST NOT", so I would expect the use of HEAD to
> require few bits transferred over the wire.

Nope -- successful responses to OPTIONS must not include entity info.

> Actually, I never thought about using OPTIONS until now :-)
> 
> Maybe we ought to have a true NOOP method?  But I'm not really
> that worried about such slight changes in the load on a server.

Oh, I wasn't thinking about server load, though it might indeed be
less using OPTIONS.

>     Does it make a difference when going through old proxies?
>     
> You mean, because HTTP/1.0 proxies don't understand OPTIONS and would
> reject such requests?  In theory, yes, although I'm not sure this would
> be an issue, because a server that wants accurate use-counts would only
> believe them from a "cooperative" cache, which is identified by
> "Connection: coop" in the request, and we said
> 
>      Note: a server might distrust such a request-header  when
>      received from an HTTP/1.0 client, which might have incorrectly
>      forwarded the Connection header.

I was going to mention this later (along with a real review of the draft),
but that is not an appropriate use of Connection.  For one thing, assuming
that all intermediaries have caches (and thus would assign any meaning to
being cooperative) is wrong.  For another, it doesn't take advantage of
the extensibility mechanism inherent in cache-control.  Instead of all
the coop negotiation, an origin server should decide whether being
cooperative is required or optional.  If it is required, then send

    Cache-control: proxy-revalidate, coop

with coop (or something similar) being defined as a modifier on
proxy-revalidate such that caches which obey the coop directive
(whatever that may imply) may ignore the proxy-revalidate.
If cooperation is considered optional, then just send

    Cache-control: coop

The advantage here is that you don't need to mess with Connection and
the directives will propagate to all recipients instead of just the
nearest neighbor on the response chain.

I still don't believe that such count-forwarding is appropriate for a
proposed standard (experimental is okay), since I don't think that
people disable caching just to record hit-counts (which are already
known not to be an accurate measure of readers).  Most people disable
caching by accident, and those that do it on purpose are normally
looking for Referer and IP/hostname (more than just a request count).

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 17 August 1996 21:26:31 UTC