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

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

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 14 Aug 96 18:23:01 MDT
Message-Id: <9608150123.AA17817@acetes.pa.dec.com>
To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
    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.

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.

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.

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.

    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.

One way for a server to deal with this case would be to send
something like
	Expires: Sun, 06 Nov 1994 08:49:37 GMT
	Cache-control: max-age=100000, max-uses=10
which would tell the HTTP/1.0 proxy not to cache things, and the
"cooperative" HTTP/1.1 proxy visible through that HTTP/1.0 proxy
that it could cache them and report its use-counts.  Then it
would indeed be useful to have the use-count relayed (naively)
by the HTTP/1.0 cache, and so OPTIONS wouldn't work.  Of course,
this depends upon trusting the HTTP/1.0 cache to obey Expires,
and I don't know if this is reasonable in practice.

-Jeff
Received on Wednesday, 14 August 1996 18:33:47 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:07 EDT