idnits 2.17.1 draft-hallam-http-proxy-note-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of lines with control characters in the document. ** The abstract seems to contain references ([Luotonen94], [Hallam96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 137 has weird spacing: '... in the exten...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1996) is 10295 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Khare96' is defined on line 251, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Khare96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Luotonen94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hallam96' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Phillip M. Hallam-Baker, W3C 2 Expires in six months email: 3 21st February 1996 5 Notification for Proxy Caches 7 9 Status of this Memo 11 This document is an Internet draft. Internet drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas 13 and its working groups. Note that other groups may also distribute 14 working information as Internet drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months and can be updated, replaced or obsoleted by other documents 18 at any time. It is inappropriate to use Internet drafts as reference 19 material or to cite them as other than as "work in progress". 21 To learn the current status of any Internet draft please check the 22 "lid-abstracts.txt" listing contained in the Internet drafts shadow 23 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or 25 ftp.isi.edu (US West coast). Further information about the IETF can 26 be found at URL: http://www.cnri.reston.va.us/ 28 Distribution of this document is unlimited. Please send comments to 29 the HTTP working group (HTTP-WG) of the Internet Engineering Task 30 Force (IETF) at < http://www.ics.uci.edu/pub/ietf/http/. This note 31 is also avaliable as a World Wide Web Consortium Working Draft 32 WD-proxy-960221, archived at 33 http://www.w3.org/pub/WWW/TR/WD-proxy-960221.html 35 Abstract 37 A mechanism to enable better functioning of proxies is proposed. 38 This mechanism allows proxies to inform a remote server about 39 transactions performed using the cache and for servers to inform 40 proxies when data becomes stale. 42 Introduction 44 Proxies [Luotonen94] and in particular caching proxies have become a 45 useful and necessary tool for many Web users. Proxy caches help 46 reduce network load by allowing pages to be served from a local 47 cache.. 49 Current proxy behavior is undesirable in a number of ways. There is 50 no mechanism whereby a proxy can be informed of changes to the 51 source data. Such a facility would permit greater use of server side 52 proxies for load balancing purposes. 54 Notification for Proxy Caches 56 Another problem with the current protocol is that a server has no 57 knowledge of hits served from a proxy's cache. This is a significant 58 concern for commercial sites whose revenues depend upon traffic 59 measurements. 61 Implementation 63 These proposals create two new headers, Proxy-Features and 64 Proxy-Instruction. In addition and extra method, NOTIFY and an 65 additional Cache-Control directive are specified. 67 Proxy-Features 69 The proxy features header is used by a proxy sending data to a 70 server. It specifies the features supported by the specified proxy. 72 Proxy-Feature = "Proxy-Features" ":" _proxy-name_ 1*(; proxy-option) 74 proxy-name = dns-name 75 proxy-option = "notify" | "loging" | log 77 log = "log" "=" uri 1*(; log-option) 78 log-option = "expires" "=" 1*digit 79 | "peak" = 1*hexdigit 81 The proxy-name field specifies the proxy offering the features. 83 The notify directive indicates that the proxy can accept 84 notification messages. The log directive indicates that the server 85 is will on request store logs of transactions performed by the proxy 86 on behalf of the particular server. The logging directive indicates 87 that the proxy is already engaged in a logging transaction. The log 88 and logging directives are mutually exclusive. 90 The log option has a required URI parameter. This should be an 91 absolute URI. The expiry an expiry date for the log file in hours. 92 if the log file data is not retrieved before this time the proxy may 93 delete it. The peak option is used to specify a binary mask 94 indicating the peak hours of the server. This mask specified as a 95 six digit hexadecimal number whose bit positions 0 to 23 correspond 96 to the time intervals 0:00 to 0:59 GMT, 1:00 to 1:59 GMT through 97 23:00 to 23:59 GMT respectively. A set bit indicates a period during 98 which server load is high and log file retrieval should be avoided. 99 If specified a peak mask should have at least one clear bit. 101 Proxy-Instruction 103 The proxy instruction header is used to reply to a proxy features 104 header. It should only be present when a Proxy-Features header was 105 present in the corresponding request. 107 Notification for Proxy Caches 109 Proxy-Instruction = "Proxy-Instruction" ":" _proxy-name_ 110 1*(; proxy-cmd-option) 112 proxy-name = dns-name 113 proxy-cmd-option = "log" | "summary" | "inform" 115 The proxy-name field specifies the proxy for which the instruction 116 is intended. Proxies may strip out headers which apply to them when 117 passing the message on. 119 Three proxy instructions are defined. These are mutually exclusive. 120 The log instruction instructs the proxy to record log data which 121 will be retreived later. The summary directive indicates that the 122 proxy may opt to provide summary as opposed to full logfiles. The 123 inform directive instructs the proxy to perform an If-Modify-Since 124 operation on each request. 126 Log Exchange Protocol 128 A proxy informs a server that it is willing to inform the server 129 when a resource is served from a cache. The server reply indicates 130 whether the server is willing to accept summary data and if so what 131 type of data is acceptable. If no Proxy-Instruction field is 132 specified the proxy will keep no log data on the servers behalf. 134 The server retrieves its log information periodically using a HTTP 135 GET method. The server may erase the log file information after 136 successfully completion of this operation. Log files are exchanged 137 in the extended log file format [Hallam96]. The data stored in such 138 logs should only contain data corresponding to a single server. 140 Example 142 GET /foo HTTP/1.1 143 Accept: text/html 144 Proxy-Features: proxy.w3.org; log=http://proxy.w3.org/logs/xxxxx.org; 145 expiry=24 147 201 OK 148 Proxy-Instruction: proxy.w3.org; log 149 Content-Type: text/html 151 ...text... 153 The server later retrieves the proxy log information: 155 Notification for Proxy Caches 157 GET /logs HTTP/1.1 158 Accept: application/www-extended-log 160 201 O.K. 161 Content-Type: application/www-extended-log 163 #Version: 1.0 164 #Start-Date: 1996-02-21 12:00 165 #End-Date: 1996-02-21 16:45.34 166 #Fields Time URI 167 12:02 /foo 168 12:03 /foo/bar 169 ... 171 Notification Protocol 173 A proxy signals that it can accept the notification protocol using 174 the notify proxy option. The server may undertake to provide 175 notification in reply using a new notify parameter of the 176 Cache-Control header. Notification takes place using the Notify 177 method. This takes as its parameter the full URI of the resource 178 which has expired. 180 Example 182 The proxy proxy.w3.org sends the remote server the following 183 request: 185 GET /foo HTTP/1.1 186 Accept: text/html 187 Proxy-Features: proxy.w3.org; notify 189 The server indicates that it is willing to provide notification: 191 201 OK 192 Cache-Control: notify 193 Content-Type: text/html 195 ...text... 197 The server subsequently notifies the proxy that the page has 198 expired: 200 NOTIFY /foo HTTP/1.1 202 Notification for Proxy Caches 204 A server must not generate a cache control notify directive unless 205 notification was offered as a proxy feature. 207 Note: servers which are capable of supporting the notification 208 protocol are not obliged to provide notification for every request. 209 Such a requirement could lead to servers becoming overloaded. It is 210 expected that use of this protocol will be restricted to a limited 211 number of high load servers and proxies. Clients should not in 212 attempt to use this facility as a matter of course. 214 Query: an alternative approach would be to piggyback notifications 215 on the back of other requests using a header tag. alternatively the 216 notification could also cause the updated page to be pushed at the 217 client. This might require a separate update directive. 219 Multiple Proxy Configurations 221 The protocols described are believed to operate correctly in 222 configurations involving multiple proxies. Additional work is 223 required before it is certain that this is the case. 225 Security considerations 227 The logging feature is vulnerable to an IP spoofing attack. An 228 attacker might use this feature to obtain logfiles. A lightweight 229 authentication technique might significantly increase the difficulty 230 of such an attack. 232 Further Work 234 The proposals made here are intended to describe structure rather 235 than implementation. It may be desirable to combine these proposals 236 with other extensions relevant to proxies. Header names should 237 therefore be considered advisory only. In particular it is likely 238 that the standards process will wish to consider PEP [khare96] as a 239 basis for implementation. 241 A proxy might perform an auditing service by authenticating the log 242 files with a digital signature or other means. 244 Phillip M. Hallam-Baker 245 hallam@w3.org 246 World Wid Web Consortium 247 Cambridge MA 249 References 251 [Khare96] 252 R. Khare, _ PEP: An Extension Mechanism for HTTP _ 253 http://www.w3.org/pub/WWW/TR/WD-http-pep 255 Notification for Proxy Caches 257 [Luotonen94] 258 A. Luotonen, _World wide Web Proxies_, Proceedings of First 259 International World-Wide Web Conference. Geneva 1994. 261 [HTTP-1.0] 262 R. Fielding, H. Frystyk, T. Berners-Lee, _ Hypertext Transfer 263 Protocol -- HTTP/1.0_ 264 http://www.w3.org/pub/WWW/Protocols/HTTP/1.0/spec.html 266 [HTTP-1.1] 267 R. Fielding, H. Frystyk, T. Berners-Lee, _ Hypertext Transfer 268 Protocol -- HTTP/1.1_ 269 http://www.w3.org/pub/WWW/Protocols/HTTP/1.1/spec.html 271 [Hallam96] 272 P. M. Hallam-Baker _ Extended Log File Format _ 273 http://www.w3.org/pub/WWW/TR/WD-logfile.html