1 |
|
2 |
Internet-Draft David Morris, BSL |
3 |
HTTP Working Group |
4 |
Expires: March 15, 1998 September 16, 1997 |
5 |
|
6 |
|
7 |
The User Agent Hint Response Header |
8 |
|
9 |
draft-ietf-http-uahint-01.txt |
10 |
|
11 |
|
12 |
STATUS OF THIS MEMO |
13 |
|
14 |
This document is an Internet-Draft. Internet-Drafts are |
15 |
working documents of the Internet Engineering Task Force |
16 |
(IETF), its areas, and its working groups. Note that other |
17 |
groups may also distribute working documents as |
18 |
Internet-Drafts. |
19 |
|
20 |
Internet-Drafts are draft documents valid for a maximum of |
21 |
six months and may be updated, replaced, or obsoleted by |
22 |
other documents at any time. It is inappropriate to use |
23 |
Internet-Drafts as reference material or to cite them other |
24 |
than as "work in progress". |
25 |
|
26 |
To learn the current status of any Internet-Draft, please |
27 |
check the "1id-abstracts.txt" listing contained in the |
28 |
Internet-drafts Shadow Directories on ftp.is.co.za |
29 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
30 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
31 |
West Coast). |
32 |
|
33 |
Distribution of this document is unlimited. Please send |
34 |
comments to the HTTP working group at |
35 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
36 |
group are archived at |
37 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
38 |
discussions about HTTP and the applications which use HTTP |
39 |
should take place on the <www-talk@w3.org> mailing list. |
40 |
|
41 |
ABSTRACT |
42 |
|
43 |
This document proposes a HTTP response header called UA-Hint, which |
44 |
can be used by applications (servers) to describe handling hints |
45 |
which will allow user agents to more accurately reflect the intent of |
46 |
the web application designer for the handling and presentation of the |
47 |
response entity. The UA-Hint header is intended to be an extensible |
48 |
general mechanism by which the application can suggest user agent |
49 |
behaviors which alter or extend the behaviors specified in HTTP/1.1 |
50 |
(RFC 2068) with the express purpose of improving the usability of the |
51 |
resulting application. Intended considerations include enablement of |
52 |
a safe POST and refined handling of the traditional history buffer. |
53 |
|
54 |
|
55 |
1 Introduction |
56 |
|
57 |
This document proposes a HTTP response header called UA-Hint, which |
58 |
can be used by applications (servers) to describe handling hints |
59 |
which will allow user agents to more accurately reflect the intent of |
60 |
the web application designer for the handling and presentation of the |
61 |
response entity. The HTTP/1.1 specification ignores many areas where |
62 |
experience has shown user friendliness would benefit if the |
63 |
application were able to more precisely influence the user agent's |
64 |
interpretation of the HTTP data stream. This document specifies a |
65 |
number of specific parameters and their interpretation while defining |
66 |
an extensible syntax which will allow user agents to reliably parse |
67 |
and ignore values which are not understood. |
68 |
|
69 |
The issues to be addressed are: |
70 |
|
71 |
Safe-Post: For many applications, it is necessary or advantageous to |
72 |
use the POST method rather than GET to submit a user agent request |
73 |
to a server. Web internationalization is one motivating example. |
74 |
Based on guidance from the various HTTP specifications and early |
75 |
drafts, all user agents should recognize the idempotency |
76 |
distinction between POST and GET by providing additional user |
77 |
prompting prior to POST. The UA-Hint header defines a Safe-Post |
78 |
directive which may be used to relax the additional user awareness |
79 |
requirements. |
80 |
|
81 |
History-List: Application designers have long been frustrated over |
82 |
their lack of control over the user agent's handling of the history |
83 |
list. This UA-Hint header proposed by this document specifies |
84 |
a number of directives which can be used to insure expected |
85 |
behavior of the user's view of the application. Optional handling |
86 |
includes setting a maximum time for retention of a response in |
87 |
the History-List and exclusion of responses from the history list. |
88 |
|
89 |
|
90 |
1.1 Revision history |
91 |
|
92 |
This is the first revision of this document. As a result of |
93 |
working group direction, all aspects of the 'SAFE' proposal in |
94 |
draft-holtman-http-safe-01.txt have been removed. The 'SAFE' |
95 |
proposal will proceed separately. |
96 |
|
97 |
Additional minor edits have been made in response to earlier |
98 |
discussion on the HTTP-WG mailing list. |
99 |
|
100 |
2 Notational Conventions and Generic Grammar |
101 |
|
102 |
This document follows the conventions described in Section 2 of the |
103 |
HTTP/1.1 specification [1]. |
104 |
|
105 |
|
106 |
3 Background |
107 |
|
108 |
The motivation for the specific directives described in this |
109 |
proposal are presented in detail in this section. |
110 |
|
111 |
3.1 Sensitive Application Protection |
112 |
|
113 |
There have been a number of posts to the www-security mailing list |
114 |
over the past several months from web application developers |
115 |
concerned about the security aspects of access to |
116 |
their applications by user's of shared browsers. There are several |
117 |
issues which have been raised: |
118 |
|
119 |
a) Re-invoking prior login screens from the History List (assuming |
120 |
that the application implements its own mechanism beyond |
121 |
WWW-Authenticate) |
122 |
b) Re-display of prior application output from the History List |
123 |
|
124 |
Section 13.13 (History Lists) of the HTTP/1.1 specification [1], |
125 |
describes the History List as different from a cache but does not |
126 |
provide any mechanism by which the server can control the History |
127 |
List. As a result, the protections desired by application authors |
128 |
concerned with the issues described in this section are almost |
129 |
impossible to achieve. We are aware of one home banking application |
130 |
which depended on the observed behavior of user agents to not retain |
131 |
the content of error responses in their History List backing store. |
132 |
|
133 |
3.2 History List Presentation Control |
134 |
|
135 |
In some applications, it is useful to include the user agent's |
136 |
History List in the overall user/application interaction paradigm. |
137 |
This surfaces in instructions like error messages which direct the |
138 |
user to return to the previous page and correct their input. |
139 |
Unfortunately, the evolving defacto standard is unpredictable |
140 |
behavior from an application perspective. Recent observations |
141 |
suggest that each user agent vendor uses a different set of |
142 |
heuristics to determine the content of the History List and when a |
143 |
response is refreshed or replaced by a subsequent response received |
144 |
later in the user's session. These heuristics , often seem different |
145 |
in each version of a product. The paper "Problems With the Expires |
146 |
Header" released by Holtman and Kaphan in July 1995 [2] describes the |
147 |
basic issues and suggests a number of alternative approaches. |
148 |
|
149 |
The History List is a resource which logically belongs to the user |
150 |
and fills a role very similar to the paper rolling off the top of the |
151 |
TTY of the past. It is a mechanism whereby the user can review past |
152 |
actions and results. The majority of web content is static from a |
153 |
navigational perspective. That is, the user navigates by clicking |
154 |
links and is presented with results which reflect the navigation. |
155 |
While the results may differ based on external factors, from the |
156 |
user's perspective the results are equivalent. |
157 |
|
158 |
However, as web protocols are adopted by organizational intranets, |
159 |
there is a growing percentage of web content which is actually |
160 |
a statefull interactive application implemented using HTTP clients and |
161 |
servers. Examples of such applications include a wide diversity of |
162 |
requirements and include such activities as online banking, customer |
163 |
support, shopping, electronic mail and personal information |
164 |
repositories. Designers of such applications generally consider and |
165 |
often integrate the expected History List behavior into their |
166 |
application paradigm. The effectiveness of the integration varies |
167 |
widely. The intent of the UA-Hint History List control directives is |
168 |
to substantially improve the user friendliness of potential web |
169 |
applications by providing the implementers with more control and |
170 |
additional control alternatives. |
171 |
|
172 |
|
173 |
4 The UA-Hint response header |
174 |
|
175 |
This header is proposed as an addition to the HTTP/1.x suite. |
176 |
|
177 |
4.1 UA-Hint |
178 |
|
179 |
The UA-Hint response header field is used to communication specific |
180 |
requests for control of the user agent's interaction with the user. |
181 |
A user agent may ignore the UA-Hint values without compromising the |
182 |
integrity of the interaction between the user agent and the server. |
183 |
However, failure of user agent implementers to respect UA-Hint values |
184 |
may have a negative impact on the interaction between end user and |
185 |
the application. |
186 |
|
187 |
UA-Hint = "UA-Hint" ":" #( hint-directive ) |
188 |
|
189 |
hint-directive = hint-name "=" hint-value *( ";" hint-dirparm ) |
190 |
|
191 |
hint-name = token ; alpha characters are |
192 |
; case insensitive |
193 |
|
194 |
hint-value = *1( token | quoted-string ) |
195 |
|
196 |
hint-dirparm = *1( token "=" ) hint-value |
197 |
|
198 |
This document proposes several specific hint-directives below, but |
199 |
this syntax is intended to accommodate many possible future extension |
200 |
syntaxes. |
201 |
|
202 |
4.2 Histage directive |
203 |
|
204 |
The Histage directive may be used to specify how long a response may |
205 |
be retained in the History List prior to deletion or refresh. |
206 |
|
207 |
Histage = "Histage" "=" 1*digit ; seconds since receipt |
208 |
|
209 |
A Histage value of zero (0) requires refresh each time the response |
210 |
would be shown as a result of History List navigation. Once the |
211 |
Histage interval has elapsed, the response must be refreshed before it |
212 |
is shown to the user. See the Histmode directive below for preferred |
213 |
methods for omitting responses from the History List. |
214 |
|
215 |
As described in Holtman and Kaphan [2], this directive introduces a |
216 |
separate notion of History List expiration from the notion of cache |
217 |
expiration. Thus, the application designer can allow a document to |
218 |
be immediately expired from a cache perspective, but retained as |
219 |
a stable reference in the History List. |
220 |
|
221 |
4.3 Histinact directive |
222 |
|
223 |
The Histinact directive may be used to specify how long a response |
224 |
may be retained in the History List prior to deletion or refresh |
225 |
expressed in terms of user agent activity. |
226 |
|
227 |
Histinact = "Histinact" "=" 1*digit ; seconds since user |
228 |
; activity |
229 |
|
230 |
This directive is similar to Histage except that expiration is based |
231 |
on the amount of time since the last user interaction with the |
232 |
user agent. It is suggested that any user activity detected by the |
233 |
user agent reset this watchdog style timer. |
234 |
|
235 |
If the response is still in active view when the Histinact timer |
236 |
expires, a brief warning should replace the response view which |
237 |
should give the user a few seconds warning. If the user doesn't |
238 |
respond, the response should be deleted from the History List and |
239 |
from the active view. |
240 |
|
241 |
This directive is intended to provide a control mechanism which |
242 |
reduces the exposure of sensitive information when a user fails |
243 |
to secure an active user agent before leaving a work station. |
244 |
By watching user activity, the user agent can leave History List |
245 |
content available for review for a longer interval using the |
246 |
activity relative timeout provided by this directive in lieu of |
247 |
the absolute timeout provided by the Histage directive. |
248 |
|
249 |
4.4 Histdist directive |
250 |
|
251 |
The Histdist directive provides an alternate user behavior model for |
252 |
controlling the duration that a response remains active in the |
253 |
History List. |
254 |
|
255 |
Histdist = "Histdist" "=" 1*digit ; responses after this |
256 |
|
257 |
This response will remain active until more than the specified number |
258 |
of responses are in the History List after this response. |
259 |
|
260 |
Examples of usage: |
261 |
|
262 |
UA-Hint: histdist=1 |
263 |
|
264 |
In this case, the response will be active while any response |
265 |
activated from this response is the next response in the |
266 |
History List. Thus, the user can flip between this response |
267 |
and the next response, but once they navigate further, this |
268 |
History List entry is deleted. |
269 |
|
270 |
|
271 |
4.5 Histmode directive |
272 |
|
273 |
The Histmode directive may be used to specify special handling of a |
274 |
response in the History list. |
275 |
|
276 |
Histmode = "Histmode" "=" ( "no" | "replace" | "popup" | |
277 |
| "explicit" ) |
278 |
|
279 |
Value interpretation: |
280 |
|
281 |
"no" This response SHOULD NOT be represented in the History List. |
282 |
The next response received by the user agent will replace |
283 |
this response. An attempt to navigate back to this response |
284 |
will present an appropriate prior entry. |
285 |
|
286 |
"replace" This response SHOULD replace the currently displayed |
287 |
response on the user display and in the History List. The |
288 |
fundamental difference between Histmode=no and |
289 |
Histmode=replace is one of when the directive is conveyed to |
290 |
the user agent. Since the UA-Hint header will be normally be |
291 |
cached, the application designer will need to choose |
292 |
carefully and perhaps include cache controls to insure proper |
293 |
cache behavior. |
294 |
|
295 |
To avoid possible spoofing, the Histmode=replace directive |
296 |
MUST be ignored if the response is not the result of the |
297 |
user activating a link or submitting an HTML FORM. The |
298 |
directive MUST also be ignored if the referring page does not |
299 |
share the same origin server host name with the original |
300 |
URL resulting in the response with the Histmode=replace |
301 |
directive (that is, the directive SHOULD be honored if the |
302 |
request URL is redirected to another host which then includes |
303 |
the directive on the response). |
304 |
|
305 |
"popup" A temporary window will be created and this response |
306 |
displayed in that window. It is recommended that the user |
307 |
agent employ a simple window with normal user agent controls |
308 |
suppressed. If the user dismisses this window without |
309 |
clicking an action displayed by the response, the focus |
310 |
should return to the window which triggered this response. |
311 |
If an active element in the window is selected, the logical |
312 |
flow should be as if that reference had been activated from |
313 |
the response from which the popup was generated. A |
314 |
Histmode=popup response is not included in the History List. |
315 |
|
316 |
"explicit" Every instance of the response entity marked |
317 |
"histmode=explicit" shall be uniquely represented in the |
318 |
History List storage mechanism. For example, if the response |
319 |
includes an HTML FORM with user entries, the History List |
320 |
instance will show the values entered or selected by the user |
321 |
when that instance was originally processed. |
322 |
|
323 |
Examples of usage: |
324 |
|
325 |
UA-Hint: histmode=replace |
326 |
|
327 |
Consider an application where the response is some form of |
328 |
notification or entity directive list. User activity related |
329 |
to the response would be to accept notifications or change |
330 |
the directives associated with an entity. The application |
331 |
might respond to a user request by creating a replacement |
332 |
response which has an action acknowledgement message at the |
333 |
top of the page and shows the entity with its new directives. |
334 |
Since the result of the users request is to invalidate the |
335 |
previous response, the histmode=replace directive/value will |
336 |
reduce user confusion by insuring that the only response |
337 |
available in the History List represents the current correct |
338 |
set of operations. |
339 |
|
340 |
Another usage would be one style of handling errors in user |
341 |
input. The original response HTML FORM the user responded to |
342 |
would be returned with the user's input filled in but the |
343 |
error input identified and error messages added to the |
344 |
response. Since this form is logically the same as the |
345 |
original it is least confusing to the user if the original |
346 |
erroneous input is deleted. |
347 |
|
348 |
UA-Hint: histmode=popup |
349 |
|
350 |
Many applications advise the user of input errors with some |
351 |
kind of temporary window while leaving the original input |
352 |
available for user correction and resubmission. This |
353 |
directive provides a web facility with similar user |
354 |
interaction characteristics. Other applications provide a |
355 |
temporary confirmation message indication an application |
356 |
completed a request or in the case of safe delete interfaces, |
357 |
requests user confirmation of their intent. |
358 |
|
359 |
4.6 Diskbuff directive |
360 |
|
361 |
The Diskbuff directive may be used to specify specific storage |
362 |
characteristics of a response retained by a user agent in support of |
363 |
its History List or response cache. |
364 |
|
365 |
Diskbuff = "Diskbuff" "=" "no" |
366 |
|
367 |
If this directive is specified, the user agent MAY NOT use any form |
368 |
of storage other than virtual memory to retain the response. Prior |
369 |
to releasing memory resources used to store this response, they |
370 |
shall be set to a meaningless value (e.g., all binary zero). |
371 |
|
372 |
This directive is intended to minimize the possibility that |
373 |
incorrectly configured shared file systems, operating system memory |
374 |
dump files, etc. will allow viewing of the response by an |
375 |
unauthorized individual. |
376 |
|
377 |
The Diskbuff=no directive explicitly overrides the provision in |
378 |
section 14.9.2 of the HTTP/1.1 specification [1] which allows a |
379 |
History buffer to store a response. |
380 |
|
381 |
|
382 |
4.7 Target directive |
383 |
|
384 |
The Target directive is similar in function to the target attribute |
385 |
included with recent additions to HTML anchors. |
386 |
|
387 |
Target = "Target" "=" ( token | quoted-string ) |
388 |
|
389 |
The value of this directive logically names a window in which this |
390 |
response should be displayed. If the window already exists, this |
391 |
response becomes the next response in that window and that window |
392 |
is restored and given the focus. If the specified target window |
393 |
does not exist, it should be created as a visual and functional clone |
394 |
of the window from which this request originated. User agents which |
395 |
do not support multiple window should ignore this directive. |
396 |
|
397 |
|
398 |
5 Caching Implications |
399 |
|
400 |
This proposal is compatible with caching controls as specified by the |
401 |
HTTP/1.1 specification. Specifically, The UA-Hint response header |
402 |
MUST be included with any response returned from a cache unless a |
403 |
caching directive is present which disables such inclusion. If a |
404 |
re-validate with the origin server included a UA-Hint response |
405 |
header, the new header should replace the currently cached value for |
406 |
the current and subsequent requests. |
407 |
|
408 |
The value of the UA-Hint header is not interpreted by a cache. |
409 |
|
410 |
|
411 |
6 Future Extensions |
412 |
|
413 |
As has been noted, this header is intended to be extensible. |
414 |
Implementers are encouraged to experiment with new values but must be |
415 |
aware that success depends on both communicating parties correctly |
416 |
interpreting such experiments. To insure correct interpretation and |
417 |
avoid conflicts between experiments conducted by different |
418 |
organizations, implementers are encouraged to document their |
419 |
experiments using the IETF draft and RFC process at the earliest |
420 |
possible time in the implementation cycle. |
421 |
|
422 |
|
423 |
7 Smooth upgrade path |
424 |
|
425 |
All directives associated with the UA-Hint header are designed to |
426 |
fail smoothly such that failure of a user agent to recognize and |
427 |
honor and directive will not prevent a user from accessing a service |
428 |
(using other mechanisms, the service may determine if a user agent |
429 |
can be expected to honor the UA-Hint header and deny a request if |
430 |
not). Its use is not required except to achieve the improved user |
431 |
interface behavior described herein. |
432 |
|
433 |
In addition, the UA-Hint header does not depend upon the HTTP/1.1 |
434 |
specification [1], hence it can be implemented by applications |
435 |
delivered by any HTTP/1.x compliant server. An HTTP/1.0 user agent |
436 |
could choose to implement this proposal prior to being fully |
437 |
compliant with HTTP/1.1. |
438 |
|
439 |
|
440 |
8 About syntax |
441 |
|
442 |
This document mainly intends to recommend a set of mechanisms for |
443 |
improving an application's control over the user's experience. The |
444 |
syntax of the corresponding header is considered less important and |
445 |
alternative headers and/or directives would be considered. |
446 |
|
447 |
|
448 |
9 Alternatives to the UA-Hint header |
449 |
|
450 |
There have been no alternatives discussed for the directives described |
451 |
in this proposal. |
452 |
|
453 |
|
454 |
10 Security considerations |
455 |
|
456 |
This proposal makes no changes to HTTP which would degrade its |
457 |
security characteristics. Several changes are proposed which if |
458 |
applied carefully, will provide additional information security for |
459 |
applications. In summary, these are: |
460 |
|
461 |
o All storage of a response on persistent storage can be blocked |
462 |
|
463 |
o Representation of a response in the History List can be blocked |
464 |
|
465 |
o New controls are proposed which limit the duration of time a |
466 |
a response can be retained in the history list. |
467 |
|
468 |
o The UA-Hint header is extensible and could be used to provide |
469 |
additional security controls, block printing, etc. |
470 |
|
471 |
|
472 |
9 Acknowledgements |
473 |
|
474 |
This specification was influenced by the early discussion of |
475 |
History List difficulties described by Holtman and Kaphan in |
476 |
"Problems with the Expires Header [2]. |
477 |
|
478 |
|
479 |
10 References |
480 |
|
481 |
[1] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", |
482 |
RFC2068, HTTP Working Group, January 1997. |
483 |
|
484 |
[2] Holtman et al, "Problems with the Expires Header", |
485 |
http://www.amazon.com/expires-report.html, July 19, 1995. |
486 |
|
487 |
|
488 |
11 Author's address |
489 |
|
490 |
David Morris |
491 |
barili systems limited |
492 |
10873 W. Estates Drive |
493 |
Cupertino, CA 95014 |
494 |
Email: dwm@xpasc.com |
495 |
|
496 |
|
497 |
Expires: March 15, 1998 |
498 |
|