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
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