INTERNET DRAFT Phillip M. Hallam-Baker, W3C
Expires in six months email: <hallam@w3.org>
21st February 1996
Notification for Proxy Caches
<draft-hallam-http-proxy-note-00.txt>
Status of this Memo
This document is an Internet draft. Internet drafts are working
documents of the Internet Engineering Task Force (IETF), its areas
and its working groups. Note that other groups may also distribute
working information as Internet drafts.
Internet Drafts are draft documents valid for a maximum of six
months and can be updated, replaced or obsoleted by other documents
at any time. It is inappropriate to use Internet drafts as reference
material or to cite them as other than as "work in progress".
To learn the current status of any Internet draft please check the
"lid-abstracts.txt" listing contained in the Internet drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or
ftp.isi.edu (US West coast). Further information about the IETF can
be found at URL: http://www.cnri.reston.va.us/
Distribution of this document is unlimited. Please send comments to
the HTTP working group (HTTP-WG) of the Internet Engineering Task
Force (IETF) at < http://www.ics.uci.edu/pub/ietf/http/. This note
is also avaliable as a World Wide Web Consortium Working Draft
WD-proxy-960221, archived at
http://www.w3.org/pub/WWW/TR/WD-proxy-960221.html
Abstract
A mechanism to enable better functioning of proxies is proposed.
This mechanism allows proxies to inform a remote server about
transactions performed using the cache and for servers to inform
proxies when data becomes stale.
Introduction
Proxies [Luotonen94] and in particular caching proxies have become a
useful and necessary tool for many Web users. Proxy caches help
reduce network load by allowing pages to be served from a local
cache..
Current proxy behavior is undesirable in a number of ways. There is
no mechanism whereby a proxy can be informed of changes to the
source data. Such a facility would permit greater use of server side
proxies for load balancing purposes.
Phillip M. Hallam-Baker Page 1
Notification for Proxy Caches
Another problem with the current protocol is that a server has no
knowledge of hits served from a proxy's cache. This is a significant
concern for commercial sites whose revenues depend upon traffic
measurements.
Implementation
These proposals create two new headers, Proxy-Features and
Proxy-Instruction. In addition and extra method, NOTIFY and an
additional Cache-Control directive are specified.
Proxy-Features
The proxy features header is used by a proxy sending data to a
server. It specifies the features supported by the specified proxy.
Proxy-Feature = "Proxy-Features" ":" _proxy-name_ 1*(; proxy-option)
proxy-name = dns-name
proxy-option = "notify" | "loging" | log
log = "log" "=" uri 1*(; log-option)
log-option = "expires" "=" 1*digit
| "peak" = 1*hexdigit
The proxy-name field specifies the proxy offering the features.
The notify directive indicates that the proxy can accept
notification messages. The log directive indicates that the server
is will on request store logs of transactions performed by the proxy
on behalf of the particular server. The logging directive indicates
that the proxy is already engaged in a logging transaction. The log
and logging directives are mutually exclusive.
The log option has a required URI parameter. This should be an
absolute URI. The expiry an expiry date for the log file in hours.
if the log file data is not retrieved before this time the proxy may
delete it. The peak option is used to specify a binary mask
indicating the peak hours of the server. This mask specified as a
six digit hexadecimal number whose bit positions 0 to 23 correspond
to the time intervals 0:00 to 0:59 GMT, 1:00 to 1:59 GMT through
23:00 to 23:59 GMT respectively. A set bit indicates a period during
which server load is high and log file retrieval should be avoided.
If specified a peak mask should have at least one clear bit.
Proxy-Instruction
The proxy instruction header is used to reply to a proxy features
header. It should only be present when a Proxy-Features header was
present in the corresponding request.
Phillip M. Hallam-Baker Page 2
Notification for Proxy Caches
Proxy-Instruction = "Proxy-Instruction" ":" _proxy-name_
1*(; proxy-cmd-option)
proxy-name = dns-name
proxy-cmd-option = "log" | "summary" | "inform"
The proxy-name field specifies the proxy for which the instruction
is intended. Proxies may strip out headers which apply to them when
passing the message on.
Three proxy instructions are defined. These are mutually exclusive.
The log instruction instructs the proxy to record log data which
will be retreived later. The summary directive indicates that the
proxy may opt to provide summary as opposed to full logfiles. The
inform directive instructs the proxy to perform an If-Modify-Since
operation on each request.
Log Exchange Protocol
A proxy informs a server that it is willing to inform the server
when a resource is served from a cache. The server reply indicates
whether the server is willing to accept summary data and if so what
type of data is acceptable. If no Proxy-Instruction field is
specified the proxy will keep no log data on the servers behalf.
The server retrieves its log information periodically using a HTTP
GET method. The server may erase the log file information after
successfully completion of this operation. Log files are exchanged
in the extended log file format [Hallam96]. The data stored in such
logs should only contain data corresponding to a single server.
Example
GET /foo HTTP/1.1
Accept: text/html
Proxy-Features: proxy.w3.org; log=http://proxy.w3.org/logs/xxxxx.org;
expiry=24
201 OK
Proxy-Instruction: proxy.w3.org; log
Content-Type: text/html
...text...
The server later retrieves the proxy log information:
Phillip M. Hallam-Baker Page 3
Notification for Proxy Caches
GET /logs HTTP/1.1
Accept: application/www-extended-log
201 O.K.
Content-Type: application/www-extended-log
#Version: 1.0
#Start-Date: 1996-02-21 12:00
#End-Date: 1996-02-21 16:45.34
#Fields Time URI
12:02 /foo
12:03 /foo/bar
...
Notification Protocol
A proxy signals that it can accept the notification protocol using
the notify proxy option. The server may undertake to provide
notification in reply using a new notify parameter of the
Cache-Control header. Notification takes place using the Notify
method. This takes as its parameter the full URI of the resource
which has expired.
Example
The proxy proxy.w3.org sends the remote server the following
request:
GET /foo HTTP/1.1
Accept: text/html
Proxy-Features: proxy.w3.org; notify
The server indicates that it is willing to provide notification:
201 OK
Cache-Control: notify
Content-Type: text/html
...text...
The server subsequently notifies the proxy that the page has
expired:
NOTIFY /foo HTTP/1.1
Phillip M. Hallam-Baker Page 4
Notification for Proxy Caches
A server must not generate a cache control notify directive unless
notification was offered as a proxy feature.
Note: servers which are capable of supporting the notification
protocol are not obliged to provide notification for every request.
Such a requirement could lead to servers becoming overloaded. It is
expected that use of this protocol will be restricted to a limited
number of high load servers and proxies. Clients should not in
attempt to use this facility as a matter of course.
Query: an alternative approach would be to piggyback notifications
on the back of other requests using a header tag. alternatively the
notification could also cause the updated page to be pushed at the
client. This might require a separate update directive.
Multiple Proxy Configurations
The protocols described are believed to operate correctly in
configurations involving multiple proxies. Additional work is
required before it is certain that this is the case.
Security considerations
The logging feature is vulnerable to an IP spoofing attack. An
attacker might use this feature to obtain logfiles. A lightweight
authentication technique might significantly increase the difficulty
of such an attack.
Further Work
The proposals made here are intended to describe structure rather
than implementation. It may be desirable to combine these proposals
with other extensions relevant to proxies. Header names should
therefore be considered advisory only. In particular it is likely
that the standards process will wish to consider PEP [khare96] as a
basis for implementation.
A proxy might perform an auditing service by authenticating the log
files with a digital signature or other means.
Phillip M. Hallam-Baker
hallam@w3.org
World Wid Web Consortium
Cambridge MA
References
[Khare96]
R. Khare, _ PEP: An Extension Mechanism for HTTP _
http://www.w3.org/pub/WWW/TR/WD-http-pep
Phillip M. Hallam-Baker Page 5
Notification for Proxy Caches
[Luotonen94]
A. Luotonen, _World wide Web Proxies_, Proceedings of First
International World-Wide Web Conference. Geneva 1994.
[HTTP-1.0]
R. Fielding, H. Frystyk, T. Berners-Lee, _ Hypertext Transfer
Protocol -- HTTP/1.0_
http://www.w3.org/pub/WWW/Protocols/HTTP/1.0/spec.html
[HTTP-1.1]
R. Fielding, H. Frystyk, T. Berners-Lee, _ Hypertext Transfer
Protocol -- HTTP/1.1_
http://www.w3.org/pub/WWW/Protocols/HTTP/1.1/spec.html
[Hallam96]
P. M. Hallam-Baker _ Extended Log File Format _
http://www.w3.org/pub/WWW/TR/WD-logfile.html
Phillip M. Hallam-Baker Page 6