1 |
|
2 |
|
3 |
HTTP Working Group J. C. Mogul, DECWRL |
4 |
Internet-Draft 6 January 1997 |
5 |
Expires: 15 July 1997 |
6 |
|
7 |
|
8 |
Forcing HTTP/1.1 proxies to revalidate responses |
9 |
|
10 |
draft-mogul-http-revalidate-00.txt |
11 |
|
12 |
|
13 |
STATUS OF THIS MEMO |
14 |
|
15 |
This document is an Internet-Draft. Internet-Drafts are |
16 |
working documents of the Internet Engineering Task Force |
17 |
(IETF), its areas, and its working groups. Note that other |
18 |
groups may also distribute working documents as |
19 |
Internet-Drafts. |
20 |
|
21 |
Internet-Drafts are draft documents valid for a maximum of |
22 |
six months and may be updated, replaced, or obsoleted by |
23 |
other documents at any time. It is inappropriate to use |
24 |
Internet-Drafts as reference material or to cite them other |
25 |
than as "work in progress." |
26 |
|
27 |
To learn the current status of any Internet-Draft, please |
28 |
check the "1id-abstracts.txt" listing contained in the |
29 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
30 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
31 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
32 |
West Coast). |
33 |
|
34 |
Distribution of this document is unlimited. Please send |
35 |
comments to the HTTP working group at |
36 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
37 |
group are archived at |
38 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
39 |
discussions about HTTP and the applications which use HTTP |
40 |
should take place on the <www-talk@w3.org> mailing list. |
41 |
|
42 |
|
43 |
ABSTRACT |
44 |
|
45 |
The HTTP/1.1 specification [1] currently defines a |
46 |
``proxy-revalidate'' Cache-control directive, which forces |
47 |
a proxy to revalidate a stale response before using it in a |
48 |
reply. There is no mechanism defined that forces a proxy, |
49 |
but not an end-client, to revalidate a fresh response. The |
50 |
lack of such a mechanism is due to an error in drafting |
51 |
RFC2068, and appears to create problems for use of the |
52 |
Authorization header, the Digest Access Authentication |
53 |
extension [2], the State Management Mechanism [3], and |
54 |
several other proposed extensions. This document discusses |
55 |
the problem and several possible solutions, and proposes to |
56 |
add a new ``proxy-maxage'' directive as the best available |
57 |
solution. |
58 |
Mogul [Page 1] |
59 |
|
60 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
61 |
|
62 |
|
63 |
TABLE OF CONTENTS |
64 |
|
65 |
1 Introduction 2 |
66 |
2 Problems with proxy-revalidate 3 |
67 |
3 Possible alternatives 5 |
68 |
3.1 Alternatives not requiring changes to RFC2068 5 |
69 |
3.2 Alternatives that require changes to RFC2068 6 |
70 |
4 Proposed solution 8 |
71 |
5 Security Considerations 10 |
72 |
6 Acknowledgements 10 |
73 |
7 References 10 |
74 |
8 Author's address 10 |
75 |
|
76 |
|
77 |
1 Introduction |
78 |
|
79 |
HTTP/1.1 introduces a ``Cache-control'' header to allow origin |
80 |
servers and clients to impose fine-grained control over the operation |
81 |
of HTTP caches. One important aspect of HTTP caching is whether a |
82 |
cache should ``revalidate'' a cached response with the origin server, |
83 |
before using the response as a cache hit. In cases where the use of |
84 |
an invalid cache entry could lead to serious error, such as the |
85 |
violation of an authentication policy, or incorrect behavior of an |
86 |
online shopping application, proper revalidation could be crucial. |
87 |
On the other hand, caching can yield significant performance |
88 |
benefits, and so we want to make caching as effective as possible. |
89 |
|
90 |
Note: HTTP caches normally revalidate a cached response by |
91 |
sending a conditional GET to the origin server. This may be |
92 |
done using the ``If-none-match'' request header or the |
93 |
``If-modified-since'' request header. If the server would |
94 |
return the same response as the cached response, the server may |
95 |
reply with a status code of 304 (Not Modified). While this |
96 |
does involve a message exchange, by avoiding the transmission |
97 |
of the entity body, a revalidation is often much cheaper than |
98 |
an unconditional retrieval. |
99 |
|
100 |
Regarding the terms ``fresh'' and ``stale'': a cached response |
101 |
is considered to be fresh if its current age is less than its |
102 |
maximum allowed age. A cached response is stale otherwise. |
103 |
Normally, only stale responses need to be revalidated; a fresh |
104 |
response is inherently usable without revalidation, until it |
105 |
reaches its maximum age. |
106 |
|
107 |
During the design of HTTP/1.1, it was realized that different |
108 |
revalidation policies might be applied to end-client caches (e.g., in |
109 |
browsers) and to intermediate proxy caches. For example, a proxy |
110 |
cache might be shared between multiple users (raising security |
111 |
considerations), or it might be operated by someone whose interests |
112 |
in reducing transmission costs do not coincide with the interest of |
113 |
the ultimate client or origin server in preserving certain kinds of |
114 |
application semantics. |
115 |
Mogul [Page 2] |
116 |
|
117 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
118 |
|
119 |
|
120 |
It was also realized that in some cases, it might sometimes be |
121 |
appropriate to configure a cache to be ``loose'' in its behavior for |
122 |
stale responses. That is, in such a situation, the cache might |
123 |
return a stale response without revalidating it. This might be done, |
124 |
for example, if the network connection between the cache and the |
125 |
origin server is not working, or if the cost or delay for |
126 |
revalidation is prohibitively high. |
127 |
|
128 |
There is an obvious potential contradiction between the occasional |
129 |
requirement for strict revalidation of certain responses, and the |
130 |
occasional desire to allow loose operation of some HTTP caches. |
131 |
HTTP/1.1 resolves this by allowing (although not encouraging) loose |
132 |
operation as the default, but by providing a protocol mechanism for |
133 |
origin servers or end-clients to insist on mandatory strict operation |
134 |
when necessary. This is done using the ``Cache-control'' header, |
135 |
which can carry a number of cache-control directives. In particular, |
136 |
these directives are defined in section 14.9 of RFC2068: |
137 |
|
138 |
- max-age=NNN |
139 |
Sets the maximum age for this response to NNN seconds. By |
140 |
itself, does not force strict revalidation behavior. |
141 |
|
142 |
- no-cache |
143 |
Prevents any caching of this response. |
144 |
|
145 |
- private |
146 |
Prevents any caching by a shared cache. |
147 |
|
148 |
- must-revalidate |
149 |
Requires that an HTTP/1.1 cache revalidate the response |
150 |
before using it, if the response is stale. |
151 |
|
152 |
- proxy-revalidate |
153 |
Requires that an HTTP/1.1 proxy cache revalidate the |
154 |
response before using it, if the response is stale; does |
155 |
not affect an end-client cache. |
156 |
|
157 |
|
158 |
2 Problems with proxy-revalidate |
159 |
|
160 |
The fundamental problem with proxy-revalidate, as defined in RFC2068, |
161 |
is that it does not require a proxy cache to revalidate a fresh |
162 |
response before using it. However, there are several circumstances |
163 |
in which it is desirable or necessary to force a proxy cache to |
164 |
revalidate a response that, to an end-client cache, would appear to |
165 |
be fresh. |
166 |
|
167 |
In section 14.8 of RFC2068, defining the ``Authorization'' header, |
168 |
this language appears: |
169 |
|
170 |
|
171 |
|
172 |
Mogul [Page 3] |
173 |
|
174 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
175 |
|
176 |
|
177 |
1. If the response includes the "proxy-revalidate" |
178 |
Cache-Control directive, the cache MAY use that response in |
179 |
replying to a subsequent request, but a proxy cache MUST |
180 |
first revalidate it with the origin server, using the |
181 |
request-headers from the new request to allow the origin |
182 |
server to authenticate the new request. |
183 |
|
184 |
While this could be read as modifying the definition of |
185 |
proxy-revalidate from section 14.9.4, it was in fact not intended as |
186 |
a modification. Rather, the author of these two sections of RFC2068 |
187 |
(me!) failed to notice the conflicting intentions of these two uses |
188 |
of proxy-revalidate. |
189 |
|
190 |
In section 2.1.2 of RFC2069 [2] (the specification of the Digest |
191 |
Access Authentication extension to HTTP/1.1), this language appears: |
192 |
|
193 |
Implementors should be aware of how authenticated |
194 |
transactions interact with proxy caches. The HTTP/1.1 |
195 |
protocol specifies that when a shared cache (see section |
196 |
13.10 of [2]) has received a request containing an |
197 |
Authorization header and a response from relaying that |
198 |
request, it MUST NOT return that response as a reply to any |
199 |
other request, unless one of two Cache-control (see section |
200 |
14.9 of [2]) directives was present in the response. If the |
201 |
original response included the ``must-revalidate'' |
202 |
Cache-control directive, the cache MAY use the entity of that |
203 |
response in replying to a subsequent request, but MUST first |
204 |
revalidate it with the origin server, using the request |
205 |
headers from the new request to allow the origin server to |
206 |
authenticate the new request. Alternatively, if the original |
207 |
response included the ``public'' Cache-control directive, the |
208 |
response entity MAY be returned in reply to any subsequent |
209 |
request. |
210 |
|
211 |
This discussion appears to be in error, since its implication that |
212 |
``must-revalidate'' always MUST cause a revalidation does not cover |
213 |
the case of apparently fresh responses. In fact, discussion with one |
214 |
of the authors of RFC2069 has confirmed that he understood that |
215 |
RFC2068 had provided a ``proxy must revalidate even if fresh'' |
216 |
directive, which it does not. |
217 |
|
218 |
In section 4.2.3 of RFCXXXX [3] (the specification of the State |
219 |
Management Mechanism for HTTP/1.1), this language appears: |
220 |
|
221 |
The origin server should send [one of] the following |
222 |
additional HTTP/1.1 response headers, depending on |
223 |
circumstances: |
224 |
|
225 |
* To suppress caching of a private document in shared caches: |
226 |
Cache-control: private. |
227 |
|
228 |
|
229 |
Mogul [Page 4] |
230 |
|
231 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
232 |
|
233 |
|
234 |
* To allow caching of a document and require that it be |
235 |
validated before returning it to the client: Cache-control: |
236 |
must-revalidate. |
237 |
|
238 |
* To allow caching of a document, but to require that proxy |
239 |
caches (not user agent caches) validate it before returning |
240 |
it to the client: Cache-control: proxy-revalidate. |
241 |
|
242 |
* To allow caching of a document and request that it be |
243 |
validated before returning it to the client (by |
244 |
``pre-expiring'' it): Cache-control: max-age=0. Not all |
245 |
caches will revalidate the document in every case. |
246 |
|
247 |
Here again there seems to be a (false) assumption that |
248 |
must-revalidate and proxy-revalidate cause revalidation even of fresh |
249 |
responses. |
250 |
|
251 |
Finally, the proposed Hit-Metering extension to HTTP/1.1 [4] depends |
252 |
on a mechanism whereby an origin server can require proxy caches to |
253 |
revalidate a response before every use, without requiring end-client |
254 |
caches to do the same thing (which would be prohibitively |
255 |
inefficient). |
256 |
|
257 |
In summary, there is a clear need for a Cache-control mechanism that |
258 |
allows an origin server to specify that a proxy must always |
259 |
revalidate a response, while allowing end-clients to cache it without |
260 |
revalidation (perhaps for a limited period). |
261 |
|
262 |
|
263 |
3 Possible alternatives |
264 |
|
265 |
3.1 Alternatives not requiring changes to RFC2068 |
266 |
Assuming that we do want a mechanism that allows an origin server to |
267 |
specify that a proxy must always revalidate a response, while |
268 |
allowing end-clients to cache it without revalidation, we could |
269 |
certainly do this by modifying the HTTP/1.1 specification proposed in |
270 |
RFC2068. Would it be possible to do this without modifying RFC2068, |
271 |
possibly by using a combination of existing Cache-control directives |
272 |
to approximate the desired behavior? |
273 |
|
274 |
One solution would simply to use ``Cache-control: private''. This |
275 |
would preserve any necessary semantics (because it would prevent any |
276 |
and all proxy caching of the response). However, it is much less |
277 |
efficient; because ``private'' prevents a shared cache from even |
278 |
storing the response, it cannot do a conditional request for |
279 |
subsequent references. Hence, this approach would lead to much |
280 |
unnecessary transmission of entity bodies when we could be using 304 |
281 |
(Not Modified) responses. |
282 |
|
283 |
Another approach would be to use ``Cache-control: proxy-revalidate, |
284 |
max-age=0''. This allows proxies to store the response and forces |
285 |
|
286 |
Mogul [Page 5] |
287 |
|
288 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
289 |
|
290 |
|
291 |
them to revalidate it on every reference. However, it also implies |
292 |
that strict end-user caches should revalidate on every reference as |
293 |
well, which could cause even more unnecessary traffic than |
294 |
``Cache-control: private'' would. |
295 |
|
296 |
In short, there does not appear to be a way to use the existing |
297 |
RFC2068 mechanisms to preserve both the necessary semantics and |
298 |
optimal cache performance. |
299 |
|
300 |
3.2 Alternatives that require changes to RFC2068 |
301 |
Several proposals have been made for modifications to RFC2068 to |
302 |
resolve this problem. |
303 |
|
304 |
We could redefine proxy-revalidate to mean ``always revalidate, even |
305 |
if the response is fresh.'' However, this would leave us either with |
306 |
no way to allow strict caches to use a response while it is fresh, or |
307 |
with no way to force loose caches to revalidate certain responses. |
308 |
|
309 |
The other proposals all involve adding one new Cache-control |
310 |
directive, while preserving the current meaning of the existing |
311 |
proxy-revalidate directive: |
312 |
|
313 |
- proxy-mustcheck |
314 |
This would mean that a proxy, but not an end-client, would |
315 |
have to revalidate the response even it is fresh |
316 |
|
317 |
- proxy-maxage=NNN |
318 |
This would mean defining separate maximum ages for proxy |
319 |
caches and for end-client caches. The existing max-age (or |
320 |
Expires) value would continue to apply to end-client |
321 |
caches, and would continue to apply to proxy caches if the |
322 |
proxy-maxage directive were not present. However, if |
323 |
proxy-maxage is present, then it would override the max-age |
324 |
(or Expires) limit for proxies, but would be ignored by |
325 |
end-clients. |
326 |
|
327 |
- agent-maxage=NNN |
328 |
This would also mean defining separate maximum ages for |
329 |
proxy caches and for end-client caches. The existing |
330 |
max-age (or Expires) value would continue to apply to proxy |
331 |
caches, and would continue to apply to end-client caches if |
332 |
the agent-maxage directive were not present. However, if |
333 |
agent-maxage is present, then it would override the max-age |
334 |
(or Expires) limit for end-clients, but would be ignored by |
335 |
proxy caches. |
336 |
|
337 |
One option would be to make either ``proxy-maxage'' or |
338 |
``agent-maxage'' always strict: that is, they would imply that a |
339 |
proxy or end-client, respectively, would be required to revalidate a |
340 |
stale response. Alternatively, they could be combined with a |
341 |
``must-revalidate'' directive to force strict behavior, but would |
342 |
otherwise allow loose behavior. |
343 |
Mogul [Page 6] |
344 |
|
345 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
346 |
|
347 |
|
348 |
Each of these proposals would solve the existing problem, would be |
349 |
simple to specify, and would probably not require significant |
350 |
implementation complexity or overhead. However, we should probably |
351 |
choose just one of these options; what are the relative merits? |
352 |
|
353 |
The proxy-mustcheck approach is clearly the simplest, but gives up |
354 |
the possibility of separate control over proxy and end-client |
355 |
expiration times. Since this orthogonality could potentially be |
356 |
useful, it seems more useful to adopt the proxy-maxage or |
357 |
agent-maxage proposals. |
358 |
|
359 |
If one assumes that this change could be made to the HTTP/1.1 |
360 |
specification before the permanent deployment of any HTTP/1.1 |
361 |
proxies, there at first seems to be no obvious reason to prefer one |
362 |
to the other. That is, this header |
363 |
|
364 |
Cache-control: max-age=10,proxy-maxage=3 |
365 |
|
366 |
and this one |
367 |
|
368 |
Cache-control: max-age=3,agent-maxage=10 |
369 |
|
370 |
both express the same semantics in the same number of bytes. |
371 |
|
372 |
However, if we also adopt the rule that proxy-maxage implies the |
373 |
presence of proxy-revalidate, then in order to express the semantics |
374 |
of |
375 |
|
376 |
Cache-control: max-age=10,proxy-maxage=3 |
377 |
|
378 |
the origin server would have to send |
379 |
|
380 |
Cache-control: max-age=3,agent-maxage=10,proxy-revalidate |
381 |
|
382 |
which is somewhat more expensive. |
383 |
|
384 |
Also, if we do adopt the Hit-metering proposal [4], the proxy-maxage |
385 |
approach seems preferable, because it would allow the necessary |
386 |
header rewriting to be accomplished by simple addition of a |
387 |
directive, rather than more elaborate rewriting. For example, if the |
388 |
origin server sends a hit-metered response with |
389 |
|
390 |
Cache-control: max-age=10 |
391 |
|
392 |
then it would be rewritten (at the appropriate proxy, if necessary; |
393 |
see [4] for details) as |
394 |
|
395 |
Cache-control: max-age=10,proxy-maxage=0 |
396 |
|
397 |
using the proxy-maxage alternative, but would have to be rewritten as |
398 |
|
399 |
|
400 |
Mogul [Page 7] |
401 |
|
402 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
403 |
|
404 |
|
405 |
Cache-control: max-age=0,agent-maxage=10 |
406 |
|
407 |
using the agent-maxage proposal. |
408 |
|
409 |
On the other hand, if we cannot make the necessary change to the |
410 |
specification before the deployment of HTTP/1.1 proxies, then the |
411 |
agent-maxage proposal is somewhat safer in terms of semantics. That |
412 |
is, if HTTP/1.1 proxies are deployed that do not understand the |
413 |
proxy-maxage directive, the use of agent-maxage will not cause these |
414 |
proxies to avoid revalidating fresh responses. This is because they |
415 |
will presumably carry a ``max-age=0'' directive, and so not appear to |
416 |
be fresh to these proxies. |
417 |
|
418 |
Unfortunately, if we fail to change the specification before the |
419 |
permanent deployment of HTTP/1.1 end-clients, then we may face a |
420 |
performance problem with the use of agent-maxage: clients that do |
421 |
not understand this new directive might do many more revalidations |
422 |
than necessary, and so cause excessive network and server loading, as |
423 |
well as unnecessary delays. |
424 |
|
425 |
Ultimately, therefore, it would be best if we made this specification |
426 |
change before any permanent deployment of HTTP/1.1 proxies or |
427 |
clients. If we do so, then it seems more efficient to use the |
428 |
proxy-maxage mechanism. |
429 |
|
430 |
|
431 |
4 Proposed solution |
432 |
|
433 |
The HTTP/1.1 specification in RFC2068 should be changed, in section |
434 |
14.9 (Cache-Control), in the following ways: |
435 |
|
436 |
- The grammar for cache-response-directive should include a |
437 |
new alternative: |
438 |
|
439 |
| "proxy-maxage" "=" delta-seconds |
440 |
|
441 |
There is no need for a corresponding change to the grammar |
442 |
for cache-request-directive. |
443 |
|
444 |
- Section 14.9.3 should include, after the second paragraph |
445 |
(which starts with ``If a response includes ...''), this |
446 |
new paragraph: |
447 |
|
448 |
If a response includes a proxy-maxage directive, |
449 |
then for a proxy cache (but not for an end-client |
450 |
cache), the maximum age specified by this directive |
451 |
overrides the maximum age specified by either the |
452 |
max-age directive or the Expires header. The |
453 |
proxy-maxage directive also implies the semantics |
454 |
of the proxy-revalidate directive (see section |
455 |
14.9.4), i.e., that the proxy MUST NOT use the |
456 |
|
457 |
Mogul [Page 8] |
458 |
|
459 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
460 |
|
461 |
|
462 |
entry after it becomes stale to respond to a |
463 |
subsequent request without first revalidating it |
464 |
with the origin server. The proxy-maxage directive |
465 |
is always ignored by an end-client. |
466 |
|
467 |
- In section 13.4, the list of response headers and |
468 |
directives implicitly allowing cachability should include |
469 |
``proxy-maxage'' after ``max-age''. |
470 |
|
471 |
- In section 14.8 (Authorization), this paragraph: |
472 |
|
473 |
1. If the response includes the "proxy-revalidate" |
474 |
Cache-Control directive, the cache MAY use that |
475 |
response in replying to a subsequent request, but a |
476 |
proxy cache MUST first revalidate it with the |
477 |
origin server, using the request-headers from the |
478 |
new request to allow the origin server to |
479 |
authenticate the new request. |
480 |
|
481 |
should become |
482 |
|
483 |
1. If the response includes the "proxy-revalidate" |
484 |
Cache-Control directive, the cache MAY use that |
485 |
response in replying to a subsequent request, but |
486 |
if the response is stale, a proxy cache MUST first |
487 |
revalidate it with the origin server, using the |
488 |
request-headers from the new request to allow the |
489 |
origin server to authenticate the new request. |
490 |
|
491 |
This paragraph |
492 |
|
493 |
2. If the response includes the "must-revalidate" |
494 |
Cache-Control directive, the cache MAY use that |
495 |
response in replying to a subsequent request, but |
496 |
all caches MUST first revalidate it with the origin |
497 |
server, using the request-headers from the new |
498 |
request to allow the origin server to authenticate |
499 |
the new request. |
500 |
|
501 |
should become |
502 |
|
503 |
2. If the response includes the "must-revalidate" |
504 |
Cache-Control directive, the cache MAY use that |
505 |
response in replying to a subsequent request, but |
506 |
if the response is stale, all caches MUST first |
507 |
revalidate it with the origin server, using the |
508 |
request-headers from the new request to allow the |
509 |
origin server to authenticate the new request. |
510 |
|
511 |
Additionally, RFC2069 [2] and RFCXXXX [3] should probably be modified |
512 |
to suggest the use of ``proxy-maxage=0'' and/or ``max-age=0, |
513 |
must-revalidate'' to force proxies to revalidate a response. |
514 |
Mogul [Page 9] |
515 |
|
516 |
Internet-Draft HTTP proxy revalidation 6 January 1997 18:22 |
517 |
|
518 |
|
519 |
5 Security Considerations |
520 |
|
521 |
The proposed Digest Access Authentication extension [2] depends upon |
522 |
a mechanism to force proxies to always revalidate certain responses. |
523 |
Whether or not the proposal in this document is adopted, the Digest |
524 |
Access Authentication extension requires modification to reflect the |
525 |
option chosen (unless the HTTP/1.1 specification is revised to make |
526 |
``proxy-revalidate'' apply to fresh as well as to stale responses.) |
527 |
|
528 |
|
529 |
6 Acknowledgements |
530 |
|
531 |
Several people contributed to my understanding of this issue, |
532 |
including Koen Holtman, Paul Leach, Ingrid Melve, and Anselm |
533 |
Baird-Smith. However, the proposal in this document is my fault |
534 |
alone. |
535 |
|
536 |
|
537 |
7 References |
538 |
|
539 |
1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk |
540 |
Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol -- |
541 |
HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997. |
542 |
|
543 |
2. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, |
544 |
E. Sink, L. Stewart. An Extension to HTTP: Digest Access |
545 |
Authentication. RFC 2069, HTTP Working Group, January, 1997. |
546 |
|
547 |
3. D. Kristol, L. Montulli. HTTP State Management Mechanism. RFC |
548 |
XXXX, HTTP Working Group, January, 1997. |
549 |
draft-ietf-http-state-mgmt-05.txt; approved by the IESG, not yet |
550 |
assigned an RFC number.. |
551 |
|
552 |
4. J. Mogul and P. Leach. Simple Hit-Metering for HTTP. Internet |
553 |
Draft draft-mogul-http-hit-metering-01.txt, HTTP Working Group, |
554 |
December, 1996. This is a work in progress.. |
555 |
|
556 |
|
557 |
8 Author's address |
558 |
|
559 |
Jeffrey C. Mogul |
560 |
Western Research Laboratory |
561 |
Digital Equipment Corporation |
562 |
250 University Avenue |
563 |
Palo Alto, California, 94305, USA |
564 |
Email: mogul@wrl.dec.com |
565 |
|
566 |
|
567 |
|
568 |
|
569 |
|
570 |
|
571 |
Mogul [Page 10] |