2004/id/draft-hallam-http-proxy-note-00.txt


   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

1	wakaba	1.1
2			INTERNET DRAFT Phillip M. Hallam-Baker, W3C
3			Expires in six months email: <hallam@w3.org>
4			21st February 1996
5
6
7			Notification for Proxy Caches
8
9			<draft-hallam-http-proxy-note-00.txt>
10
11			Status of this Memo
12
13			This document is an Internet draft. Internet drafts are working
14			documents of the Internet Engineering Task Force (IETF), its areas
15			and its working groups. Note that other groups may also distribute
16			working information as Internet drafts.
17
18			Internet Drafts are draft documents valid for a maximum of six
19			months and can be updated, replaced or obsoleted by other documents
20			at any time. It is inappropriate to use Internet drafts as reference
21			material or to cite them as other than as "work in progress".
22
23			To learn the current status of any Internet draft please check the
24			"lid-abstracts.txt" listing contained in the Internet drafts shadow
25			directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
26			munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or
27			ftp.isi.edu (US West coast). Further information about the IETF can
28			be found at URL: http://www.cnri.reston.va.us/
29
30			Distribution of this document is unlimited. Please send comments to
31			the HTTP working group (HTTP-WG) of the Internet Engineering Task
32			Force (IETF) at < http://www.ics.uci.edu/pub/ietf/http/. This note
33			is also avaliable as a World Wide Web Consortium Working Draft
34			WD-proxy-960221, archived at
35			http://www.w3.org/pub/WWW/TR/WD-proxy-960221.html
36
37			Abstract
38
39			A mechanism to enable better functioning of proxies is proposed.
40			This mechanism allows proxies to inform a remote server about
41			transactions performed using the cache and for servers to inform
42			proxies when data becomes stale.
43
44			Introduction
45
46			Proxies [Luotonen94] and in particular caching proxies have become a
47			useful and necessary tool for many Web users. Proxy caches help
48			reduce network load by allowing pages to be served from a local
49			cache..
50
51			Current proxy behavior is undesirable in a number of ways. There is
52			no mechanism whereby a proxy can be informed of changes to the
53			source data. Such a facility would permit greater use of server side
54			proxies for load balancing purposes.
55
56			Phillip M. Hallam-Baker Page 1
57
58
59
60			Notification for Proxy Caches
61
62			Another problem with the current protocol is that a server has no
63			knowledge of hits served from a proxy's cache. This is a significant
64			concern for commercial sites whose revenues depend upon traffic
65			measurements.
66
67			Implementation
68
69			These proposals create two new headers, Proxy-Features and
70			Proxy-Instruction. In addition and extra method, NOTIFY and an
71			additional Cache-Control directive are specified.
72
73			Proxy-Features
74
75			The proxy features header is used by a proxy sending data to a
76			server. It specifies the features supported by the specified proxy.
77
78
79			Proxy-Feature = "Proxy-Features" ":" _proxy-name_ 1*(; proxy-option)
80
81			proxy-name = dns-name
82			proxy-option = "notify" \| "loging" \| log
83
84			log = "log" "=" uri 1*(; log-option)
85			log-option = "expires" "=" 1*digit
86			\| "peak" = 1*hexdigit
87
88
89
90			The proxy-name field specifies the proxy offering the features.
91
92			The notify directive indicates that the proxy can accept
93			notification messages. The log directive indicates that the server
94			is will on request store logs of transactions performed by the proxy
95			on behalf of the particular server. The logging directive indicates
96			that the proxy is already engaged in a logging transaction. The log
97			and logging directives are mutually exclusive.
98
99			The log option has a required URI parameter. This should be an
100			absolute URI. The expiry an expiry date for the log file in hours.
101			if the log file data is not retrieved before this time the proxy may
102			delete it. The peak option is used to specify a binary mask
103			indicating the peak hours of the server. This mask specified as a
104			six digit hexadecimal number whose bit positions 0 to 23 correspond
105			to the time intervals 0:00 to 0:59 GMT, 1:00 to 1:59 GMT through
106			23:00 to 23:59 GMT respectively. A set bit indicates a period during
107			which server load is high and log file retrieval should be avoided.
108			If specified a peak mask should have at least one clear bit.
109
110			Proxy-Instruction
111
112			The proxy instruction header is used to reply to a proxy features
113			header. It should only be present when a Proxy-Features header was
114			present in the corresponding request.
115
116			Phillip M. Hallam-Baker Page 2
117
118
119
120			Notification for Proxy Caches
121
122
123			Proxy-Instruction = "Proxy-Instruction" ":" _proxy-name_
124			1*(; proxy-cmd-option)
125
126			proxy-name = dns-name
127			proxy-cmd-option = "log" \| "summary" \| "inform"
128
129
130
131			The proxy-name field specifies the proxy for which the instruction
132			is intended. Proxies may strip out headers which apply to them when
133			passing the message on.
134
135			Three proxy instructions are defined. These are mutually exclusive.
136			The log instruction instructs the proxy to record log data which
137			will be retreived later. The summary directive indicates that the
138			proxy may opt to provide summary as opposed to full logfiles. The
139			inform directive instructs the proxy to perform an If-Modify-Since
140			operation on each request.
141
142			Log Exchange Protocol
143
144			A proxy informs a server that it is willing to inform the server
145			when a resource is served from a cache. The server reply indicates
146			whether the server is willing to accept summary data and if so what
147			type of data is acceptable. If no Proxy-Instruction field is
148			specified the proxy will keep no log data on the servers behalf.
149
150			The server retrieves its log information periodically using a HTTP
151			GET method. The server may erase the log file information after
152			successfully completion of this operation. Log files are exchanged
153			in the extended log file format [Hallam96]. The data stored in such
154			logs should only contain data corresponding to a single server.
155
156			Example
157
158
159			GET /foo HTTP/1.1
160			Accept: text/html
161			Proxy-Features: proxy.w3.org; log=http://proxy.w3.org/logs/xxxxx.org;
162			expiry=24
163
164
165
166			201 OK
167			Proxy-Instruction: proxy.w3.org; log
168			Content-Type: text/html
169
170			...text...
171
172
173			The server later retrieves the proxy log information:
174
175
176
177			Phillip M. Hallam-Baker Page 3
178
179
180
181			Notification for Proxy Caches
182
183			GET /logs HTTP/1.1
184			Accept: application/www-extended-log
185
186
187
188			201 O.K.
189			Content-Type: application/www-extended-log
190
191			#Version: 1.0
192			#Start-Date: 1996-02-21 12:00
193			#End-Date: 1996-02-21 16:45.34
194			#Fields Time URI
195			12:02 /foo
196			12:03 /foo/bar
197			...
198
199
200			Notification Protocol
201
202			A proxy signals that it can accept the notification protocol using
203			the notify proxy option. The server may undertake to provide
204			notification in reply using a new notify parameter of the
205			Cache-Control header. Notification takes place using the Notify
206			method. This takes as its parameter the full URI of the resource
207			which has expired.
208
209			Example
210
211			The proxy proxy.w3.org sends the remote server the following
212			request:
213
214
215			GET /foo HTTP/1.1
216			Accept: text/html
217			Proxy-Features: proxy.w3.org; notify
218
219
220			The server indicates that it is willing to provide notification:
221
222
223			201 OK
224			Cache-Control: notify
225			Content-Type: text/html
226
227			...text...
228
229
230			The server subsequently notifies the proxy that the page has
231			expired:
232
233
234			NOTIFY /foo HTTP/1.1
235
236
237			Phillip M. Hallam-Baker Page 4
238
239
240
241			Notification for Proxy Caches
242
243			A server must not generate a cache control notify directive unless
244			notification was offered as a proxy feature.
245
246			Note: servers which are capable of supporting the notification
247			protocol are not obliged to provide notification for every request.
248			Such a requirement could lead to servers becoming overloaded. It is
249			expected that use of this protocol will be restricted to a limited
250			number of high load servers and proxies. Clients should not in
251			attempt to use this facility as a matter of course.
252
253			Query: an alternative approach would be to piggyback notifications
254			on the back of other requests using a header tag. alternatively the
255			notification could also cause the updated page to be pushed at the
256			client. This might require a separate update directive.
257
258			Multiple Proxy Configurations
259
260			The protocols described are believed to operate correctly in
261			configurations involving multiple proxies. Additional work is
262			required before it is certain that this is the case.
263
264			Security considerations
265
266			The logging feature is vulnerable to an IP spoofing attack. An
267			attacker might use this feature to obtain logfiles. A lightweight
268			authentication technique might significantly increase the difficulty
269			of such an attack.
270
271			Further Work
272
273			The proposals made here are intended to describe structure rather
274			than implementation. It may be desirable to combine these proposals
275			with other extensions relevant to proxies. Header names should
276			therefore be considered advisory only. In particular it is likely
277			that the standards process will wish to consider PEP [khare96] as a
278			basis for implementation.
279
280			A proxy might perform an auditing service by authenticating the log
281			files with a digital signature or other means.
282
283
284			Phillip M. Hallam-Baker
285			hallam@w3.org
286			World Wid Web Consortium
287			Cambridge MA
288
289
290			References
291
292			[Khare96]
293			R. Khare, _ PEP: An Extension Mechanism for HTTP _
294			http://www.w3.org/pub/WWW/TR/WD-http-pep
295
296
297			Phillip M. Hallam-Baker Page 5
298
299
300
301			Notification for Proxy Caches
302
303			[Luotonen94]
304			A. Luotonen, _World wide Web Proxies_, Proceedings of First
305			International World-Wide Web Conference. Geneva 1994.
306
307			[HTTP-1.0]
308			R. Fielding, H. Frystyk, T. Berners-Lee, _ Hypertext Transfer
309			Protocol -- HTTP/1.0_
310			http://www.w3.org/pub/WWW/Protocols/HTTP/1.0/spec.html
311
312			[HTTP-1.1]
313			R. Fielding, H. Frystyk, T. Berners-Lee, _ Hypertext Transfer
314			Protocol -- HTTP/1.1_
315			http://www.w3.org/pub/WWW/Protocols/HTTP/1.1/spec.html
316
317			[Hallam96]
318			P. M. Hallam-Baker _ Extended Log File Format _
319			http://www.w3.org/pub/WWW/TR/WD-logfile.html
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357			Phillip M. Hallam-Baker Page 6
358