W3C: WD-proxy-960221

Notification for Proxy Caches

W3C Working Draft WD-proxy-960221

This version:
http://www.w3.org/pub/WWW/TR/WD-proxy-960221.html
Latest version:
http://www.w3.org/pub/WWW/TR/WD-proxy.html
Authors:
Phillip M. Hallam-Baker <hallam@w3.org>

Status of this document

This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR

Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.

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.

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.

	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:

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

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.

References

[Khare96]
R. Khare, PEP: An Extension Mechanism for HTTP http://www.w3.org/pub/WWW/TR/WD-http-pep
[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