Internet-Draft David Morris, BSL HTTP Working Group Expires: September 21, 1997 March 21, 1997 The User Agent Hint Response Header draft-ietf-http-uahint-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 documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may 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 other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-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). Distribution of this document is unlimited. Please send comments to the HTTP working group at . Discussions of the working group are archived at . General discussions about HTTP and the applications which use HTTP should take place on the mailing list. ABSTRACT This document proposes a HTTP response header called UA-Hint, which can be used by applications (servers) to describe handling hints which will allow user agents to more accurately reflect the intent of the web application designer for the handling and presentation of the response entity. The UA-Hint header is intended to be an extensible general mechanism by which the application can suggest user agent behaviors which alter or extend the behaviors specified in HTTP/1.1 (RFC 2068) with the express purpose of improving the usability of the resulting application. Intended considerations include enablement of a safe POST and refined handling of the traditional history buffer. 1 Introduction This document proposes a HTTP response header called UA-Hint, which can be used by applications (servers) to describe handling hints which will allow user agents to more accurately reflect the intent of the web application designer for the handling and presentation of the response entity. The HTTP/1.1 specification ignores many areas where experience has shown user friendliness would benefit if the application were able to more precisely influence the user agent's interpretation of the HTTP data stream. This document specifies a number of specific parameters and their interpretation while defining an extensible syntax which will allow user agents to reliably parse and ignore values which are not understood. The issues to be addressed are: Safe-Post: For many applications, it is necessary or advantageous to use the POST method rather than GET to submit a user agent request to a server. Web internationalization is one motivating example. Based on guidance from the various HTTP specifications and early drafts, all user agents should recognize the idempotency distinction between POST and GET by providing additional user prompting prior to POST. The UA-Hint header defines a Safe-Post directive which may be used to relax the additional user awareness requirements. History-List: Application designers have long been frustrated over their lack of control over the user agent's handling of the history list. This UA-Hint header proposed by this document specifies a number of directives which can be used to insure expected behavior of the user's view of the application. Optional handling includes setting a maximum time for retention of a response in the History-List and exclusion of responses from the history list. 1.1 Revision history This is the first version of this document. Using different syntax, it encompasses the functionality described in draft-holtman-http-safe-01.txt. 2 Notational Conventions and Generic Grammar This document follows the conventions described in Section 2 of the HTTP/1.1 specification [1]. 3 Background The motivation for the specific directives described in this proposal are presented in detail in this section. 3.1 Safe Request with Content Body According to Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1], POST requests are assumed to be `unsafe' by default. `Unsafe' means `causes side effects for which the user will be held accountable'. If the POST request is unsafe, explicit user confirmation is necessary before the request is repeated. User agents will repeat POST requests when the user presses the RELOAD button while a POST result is displayed, or when the history function is used to redisplay a POST result which is no longer in the history buffer. The necessary confirmation dialog often takes the form of a `repost form data?' dialog box. The dialog is confusing to many users, and slows down navigation in any case. In theory, if the repeated POST request is safe, the user-unfriendly confirmation dialog can be omitted. However, up till now, HTTP has no mechanism by which agents can tell if POST requests are safe. This proposal adds such a mechanism. Many content authors have managed to avoid the confirmation dialog problem by using GETs for form submission instead of safe POSTs. However, this escape is not possible for forms: a) which are (sometimes) used to submit large amounts of data b) which are (sometimes) used to submit data in a charset other than ISO-8859-1. Case b) will be the increasingly common; web internationalization [2] makes it necessary to use the POST method for form submission. Note: Actually, according to the authors of [2], web internationalization makes it necessary to use requests with request bodies. This rules out the use of the only methods which are safe under HTTP/1.1: GET and HEAD. A new GET-WITH-BODY method could be defined, but it would be unsafe by default under HTTP/1.1, so GET-WITH-BODY would also need something like the mechanism in this proposal. It is therefore considered important to eliminate the unnecessary confirmation dialogs for safe POSTs as soon as possible. They are a counter-incentive to the upgrading of GET based forms services (like search engines) to internationalized POST based forms services. 3.2 Sensitive Application Protection There have been a number of posts to the www-security mailing list over the past several months from web application developers concerned about the security aspects of access to their applications by user's of shared browsers. There are several issues which have been raised: a) Re-invoking prior login screens from the History List (assuming that the application implements its own mechanism beyond WWW-Authenticate) b) Re-display of prior application output from the History List Section 13.13 (History Lists) of the HTTP/1.1 specification [1], describes the History List as different from a cache but does not provide any mechanism by which the server can control the History List. As a result, the protections desired by application authors concerned with the issues described in this section are almost impossible to achieve. We are aware of one home banking application which depended on the observed behavior of user agents to not retain the content of error responses in their History List backing store. 3.3 History List Presentation Control In some applications, it is useful to include the user agent's History List in the overall user/application interaction paradigm. This surfaces in instructions like error messages which direct the user to return to the previous page and correct their input. Unfortunately, the evolving defacto standard is unpredictable behavior from an application perspective. Recent observations suggest that each user agent vendor uses a different set of heuristics to determine the content of the History List and when a response is refreshed or replaced by a subsequent response received later in the user's session. These heuristics , often seem different in each version of a product. The paper "Problems With the Expires Header" released by Holtman and Kaphan in July 1995 [3] describes the basic issues and suggests a number of alternative approaches. The History List is a resource which logically belongs to the user and fills a role very similar to the paper rolling off the top of the TTY of the past. It is a mechanism whereby the user can review past actions and results. The majority of web content is static from a navigational perspective. That is, the user navigates by clicking links and is presented with results which reflect the navigation. While the results may differ based on external factors, from the user's perspective the results are equivalent. However, as web protocols are adopted by organizational intranets, there is a growing percentage of web content which is actually a statefull interactive application implemented using HTTP clients and servers. Examples of such applications include a wide diversity of requirements and include such activities as online banking, customer support, shopping, electronic mail and personal information repositories. Designers of such applications generally consider and often integrate the expected History List behavior into their application paradigm. The effectiveness of the integration varies widely. The intent of the UA-Hint History List control directives is to substantially improve the user friendliness of potential web applications by providing the implementers with more control and additional control alternatives. 4 The UA-Hint response header This header is proposed as an addition to the HTTP/1.x suite. 4.1 UA-Hint The UA-Hint response header field is used to communication specific requests for control of the user agent's interaction with the user. A user agent may ignore the UA-Hint values without compromising the integrity of the interaction between the user agent and the server. However, failure of user agent implementers to respect UA-Hint values may have a negative impact on the interaction between end user and the application. UA-Hint = "UA-Hint" ":" #( hint-directive ) hint-directive = hint-name "=" hint-value *( ";" hint-dirparm ) hint-name = token ; alpha characters are ; case insensitive hint-value = *1( token | quoted-string ) hint-dirparm = *1( token "=" ) hint-value This document proposes several specific hint-directives below, but this syntax is intended to accommodate many possible future extension syntaxes. 4.2 Resubmit directive The Resubmit directive is used to modify the conditions under which a request may be resubmitted from the user agent to the origin server. Resubmit = "Resubmit" "=" ( "no" | "safe" | "prompt" ) Value interpretation: "no" This request which resulted in this response MAY NOT be resubmitted, either silently as a result of History List navigation or explicitly as a result of a user refresh request. If the user repeats the original action (e.g., clicking a FORM button), the user agent SHOULD warn the user. The user agent is encouraged to provide a meaningful message to the user when a refresh is requested or would otherwise be requested because the History List response is no longer available. "safe" | "prompt" Indicates whether the corresponding request is safe in the sense of Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1]. An example: UA-Hint: resubmit=safe indicates that an otherwise unsafe method may be silently repeated. That is, it is not necessary to prompt the user before re-submitting a POST request. Resubmit=safe has no impact on a GET or HEAD request which is safe by definition. If resubmit=prompt is included in the response to a GET request, the user agent should prompt the user before resubmitting the request. Note: User agents can use the received information about safety when repeating an earlier request. If the request is known to be safe, it can be silently repeated without asking for user confirmation. Note 2: See caching implications below. It may be desirable to over-ride proxy cache default behaviors using appropriate headers when the defined safe interpretation of a METHOD is modified. 4.3 Histage directive The Histage directive may be used to specify how long a response may be retained in the History List prior to deletion or refresh. Histage = "Histage" "=" 1*digit ; seconds since receipt A Histage value of zero (0) requires refresh each time the response would be shown as a result of History List navigation. Once the Histage interval has elapsed, the response must be refreshed under the terms of the Resubmit directive before it is shown to the user. See the Histmode directive below for preferred methods for omitting responses from the History List. As described in Holtman and Kaphan [3], this directive introduces a separate notion of History List expiration from the notion of cache expiration. Thus, the application designer can allow a document to be immediately expired from a cache perspective, but retained as a stable reference in the History List. 4.4 Histinact directive The Histinact directive may be used to specify how long a response may be retained in the History List prior to deletion or refresh expressed in terms of user agent activity. Histinact = "Histinact" "=" 1*digit ; seconds since user ; activity This directive is similar to Histage except that expiration is based on the amount of time since the last user interaction with the user agent. It is suggested that any user activity detected by the user agent reset this watchdog style timer. If the response is still in active view when the Histinact timer expires, a brief warning should replace the response view which should give the user a few seconds warning. If the user doesn't respond, the response should be deleted from the History List and from the active view. This directive is intended to provide a control mechanism which reduces the exposure of sensitive information when a user fails to secure an active user agent before leaving a work station. By watching user activity, the user agent can leave History List content available for review for a longer interval using the activity relative timeout provided by this directive in lieu of the absolute timeout provided by the Histage directive. 4.5 Histdist directive The Histdist directive provides an alternate user behavior model for controlling the duration that a response remains active in the History List. Histdist = "Histdist" "=" 1*digit ; responses after this This response will remain active until more than the specified number of responses are in the History List after this response. Examples of usage: UA-Hint: histdist=1 In this case, the response will be active while any response activated from this response is the next response in the History List. Thus, the user can flip between this response and the next response, but once they navigate further, this History List entry is deleted. 4.6 Histmode directive The Histmode directive may be used to specify special handling of a response in the History list. Histmode = "Histmode" "=" ( "no" | "replace" | "popup" | | "explicit" ) Value interpretation: "no" This response SHOULD NOT be represented in the History List. The next response received by the user agent will replace this response. An attempt to navigate back to this response will present an appropriate prior entry. "replace" This response SHOULD replace the currently displayed response on the user display and in the History List. The fundamental difference between Histmode=no and Histmode=replace is one of when the directive is conveyed to the user agent. Since the UA-Hint header will be normally be cached, the application designer will need to choose carefully and perhaps include cache controls to insure proper cache behavior. To avoid possible spoofing, the Histmode=replace directive MUST be ignored if the response is not the result of the user activating a link or submitting an HTML FORM. The directive MUST also be ignored if the referring page does not share the same origin server host name with the original URL resulting in the response with the Histmode=replace directive (that is, the directive SHOULD be honored if the request URL is redirected to another host which then includes the directive on the response). "popup" A temporary window will be created and this response displayed in that window. It is recommended that the user agent employ a simple window with normal user agent controls suppressed. If the user dismisses this window without clicking an action displayed by the response, the focus should return to the window which triggered this response. If an active element in the window is selected, the logical flow should be as if that reference had been activated from the response from which the popup was generated. A Histmode=popup response is not included in the History List. "explicit" Every instance of the response entity marked "histmode=explicit" shall be uniquely represented in the History List storage mechanism. For example, if the response includes an HTML FORM with user entries, the History List instance will show the values entered or selected by the user when that instance was originally processed. Examples of usage: UA-Hint: histmode=replace Consider an application where the response is some form of notification or entity directive list. User activity related to the response would be to accept notifications or change the directives associated with an entity. The application might respond to a user request by creating a replacement response which has an action acknowledgement message at the top of the page and shows the entity with its new directives. Since the result of the users request is to invalidate the previous response, the histmode=replace directive/value will reduce user confusion by insuring that the only response available in the History List represents the current correct set of operations. Another usage would be one style of handling errors in user input. The original response HTML FORM the user responded to would be returned with the user's input filled in but the error input identified and error messages added to the response. Since this form is logically the same as the original it is least confusing to the user if the original erroneous input is deleted. UA-Hint: histmode=popup Many applications advise the user of input errors with some kind of temporary window while leaving the original input available for user correction and resubmission. This directive provides a web facility with similar user interaction characteristics. Other applications provide a temporary confirmation message indication an application completed a request or in the case of safe delete interfaces, requests user confirmation of their intent. 4.7 Diskbuff directive The Diskbuff directive may be used to specify specific storage characteristics of a response retained by a user agent in support of its History List or response cache. Diskbuff = "Diskbuff" "=" "no" If this directive is specified, the user agent MAY NOT use any form of storage other than virtual memory to retain the response. Prior to releasing memory resources used to store this response, they shall be set to a meaningless value (e.g., all binary zero). This directive is intended to minimize the possibility that incorrectly configured shared file systems, operating system memory dump files, etc. will allow viewing of the response by an unauthorized individual. The Diskbuff=no directive explicitly overrides the provision in section 14.9.2 of the HTTP/1.1 specification [1] which allows a History buffer to store a response. 4.8 Target directive The Target directive is similar in function to the target attribute included with recent additions to HTML anchors. Target = "Target" "=" ( token | quoted-string ) The value of this directive logically names a window in which this response should be displayed. If the window already exists, this response becomes the next response in that window and that window is restored and given the focus. If the specified target window does not exist, it should be created as a visual and functional clone of the window from which this request originated. User agents which do not support multiple window should ignore this directive. 4.9 Caching Implications This proposal is compatible with caching controls as specified by the HTTP/1.1 specification. Specifically, The UA-Hint response header MUST be included with any response returned from a cache unless a caching directive is present which disables such inclusion. If a re-validate with the origin server included a UA-Hint response header, the new header should replace the currently cached value for the current and subsequent requests. The value of the UA-Hint header is not interpreted by a cache. 4.10 Future Extensions As has been noted, this header is intended to be extensible. Implementers are encouraged to experiment with new values but must be aware that success depends on both communicating parties correctly interpreting such experiments. To insure correct interpretation and avoid conflicts between experiments conducted by different organizations, implementers are encouraged to document their experiments using the IETF draft and RFC process at the earliest possible time in the implementation cycle. 5 Smooth upgrade path All directives associated with the UA-Hint header are designed to fail smoothly such that failure of a user agent to recognize and honor and directive will not prevent a user from accessing a service (using other mechanisms, the service may determine if a user agent can be expected to honor the UA-Hint header and deny a request if not). Its use is not required except to achieve the improved user interface behavior described herein. In addition, the UA-Hint header does not depend upon the HTTP/1.1 specification [1], hence it can be implemented by applications delivered by any HTTP/1.x compliant server. An HTTP/1.0 user agent could choose to implement this proposal prior to being fully compliant with HTTP/1.1. 6 About syntax This document mainly intends to recommend a set of mechanisms for improving an application's control over the user's experience. The syntax of the corresponding header is considered less important and alternative headers and/or directives would be considered. 7 Alternatives to the UA-Hint header A number of alternative ways to solve the resubmit confirmation dialog problem have been proposed. These alternative solutions would make the introduction of the Resubmit=Safe directive unnecessary. There have been no alternatives discussed for the other directives described in this proposal. The following sections summarize alternatives to the Resubmit=Safe directive. 7.1 Safe header Internet draft-holtman-http-safe-01.txt describes an alternative which uses a unique header, "Safe", to modify the unsafe method semantics of POST. This proposal is intended to replace that proposal by incorporating that proposal along with a cluster of related user experience control functions. 7.1 GET-WITH-BODY If a new HTTP/1.x GET-WITH-BODY is defined, one would not need the resubmit=safe directive anymore, one could simply define GET-WITH-BODY as always safe. However, it has been shown that some ugly extensions to the HTML FORM syntax would be needed to provide the same level of downwards compatibility with existing browsers that Safe can provide, for example:
...
. One could say that a GET-WITH-BODY manages to keep HTTP clean at the cost of adding extensions to HTML. The authors of this draft prefer to keep HTML clean by adding the resubmit=Safe extension to HTTP. Note that the UA-Hint header and resubmit=safe directive does not block the introduction of a GET-WITH-BODY in the long run. 7.2 Link The need for a confirmation dialog can also be eliminated by offering the user agent an alternative to resubmitting the POST request altogether. A POST result could, for example, have a Link header which would contain an URL from which the result can be retrieved again with a GET request. However, this Link URL cannot be very long: if it were too long, the request would fail due to user agent, proxy, or origin server limitations. This length restriction would make the Link solution hard to use in the general case. 7.3 Conclusion An HTTP extension header such as the UA-Hint header and resubmit=Safe directive seems to be the best solution in the current framework because it combines the override of the unsafe condition of a POST with other user agent hints which also impact the quality of the user's experience. This combination retains much of the implementation simplicity of the earlier Safe: header proposal while providing additional directives with a single new extensible header. The proposed resubmit=safe directive would eliminate a counter-incentive to web internationalization, and the author feels that these counter-incentives need to be eliminated as soon as possible. It is therefore proposed to introduce the UA-Hint and resubmit=safe directive into HTTP/1.x without undue delay. 8 Security considerations This proposal makes no changes to HTTP which would degrade its security characteristics. Several changes are proposed which if applied carefully, will provide additional information security for applications. In summary, these are: o All storage of a response on persistent storage can be blocked o Representation of a response in the History List can be blocked o New controls are proposed which limit the duration of time a a response can be retained in the history list. o The UA-Hint header is extensible and could be used to provide additional security controls, block printing, etc. 9 Acknowledgements This specification was influenced by the early discussion of History List difficulties described by Holtman and Kaphan in "Problems with the Expires Header [3] and by the earlier IETF draft draft-holtman-http-safe-01.txt from which the bulk of the text describing the resubmit=safe directive was extracted. 10 References [1] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, HTTP Working Group, January 1997. [2] Yergeau et al, "Internationalization of the Hypertext Markup Language", Internet-Draft draft-ietf-html-i18n-05.txt, HTML Working Group, August 7, 1996. [3] Holtman et al, "Problems with the Expires Header", http://www.amazon.com/expires-report.html, July 19, 1995. 11 Author's address David Morris barili systems limited 10873 W. Estates Drive Cupertino, CA 95014 Email: dwm@xpasc.com Expires: September 21, 1997