INTERNET DRAFT Phillip M. Hallam-Baker, W3C Expires in six months email: 21st February 1996 Notification for Proxy Caches 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