- From: Paul Burchard <burchard@cs.princeton.edu>
- Date: Sun, 13 Aug 95 21:53:31 -0400
- To: Brian Behlendorf <brian@organic.com>
- Cc: Koen Holtman <koen@win.tue.nl>, www-talk@www10.w3.org, "Balint Nagy Endre" <bne@bne.ind.eunet.hu>
Talking to several people privately, I've been convinced that "bundled request" reporting information would most naturally be placed into a Forwarded header, instead of a Pragma. Forwarded headers have similar semantics to Pragmas (they accumulate and must be passed on down the line of proxies), and already represent a primitive form of reporting. So, keeping in mind Brian Behlendorf's requirements list, here is a more refined proposal containing two extensions of the Forwarded header. I think both should be considered, since they provide different balances between the demands of proxies and servers. The first (proxy-biased) extension, which only requires constant storage per cached item at the proxy, adds a "count" clause to the Forwarded header: Forwarded: by http://proxy/ count 34 This is equivalent to the hits pragma, except that hit counts are assigned to specific "leaf" proxies. To be precise: The count is reset to zero after the proxy forwards a request. Thereafter, every request for the resource received _without_ any Forwarded headers increases the count by one; every request _with_ one or more Forwarded headers simply contributes its Forwarded headers to the eventual list of headers to be submitted by the proxy. The second extension, which supplies a more acceptable level of information, but at the cost of proxy storage proportional to the number of hits received, adds an "mfor" (multiple-for) clause to the Forwarded header: Forwarded: by http://proxy/ mfor Pr5CH77RbN7g0HTux90R7GHK Here, the argument of the "mfor" clause is a compressed logfile, representing those requests received by the proxy for this resource since last forwarding, which did not contain any Forwarded headers of their own (as before, requests forwarded from proxies upstream simply contribute their own Forwarded headers). What needs to be decided more precisely is (a) the compression algorithm to be applied to the logfile, and (b) the format and fields of the logfile. Brian Behlendorf suggested a good minimum set of log fields: host, timestamp, referer (although some sort of "host hiding" should probably be supported for privacy/security reasons). Any suggestions for the compression? It would be nice to have something that could be used incrementally by the proxy to save space. -------------------------------------------------------------------- Paul Burchard <burchard@cs.princeton.edu> ``I'm still learning how to count backwards from infinity...'' --------------------------------------------------------------------
Received on Sunday, 13 August 1995 21:59:55 UTC