WD-proxy-960221
WD-proxy-960221This 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.
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.
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.
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.
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.
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.
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.
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 ...
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.
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.
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.
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.
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.