Internet-Draft David Morris, BSL HTTP Working Group Expires: March 15, 1998 September 16, 1997 The User Agent Hint Response Header draft-ietf-http-uahint-01.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 revision of this document. As a result of working group direction, all aspects of the 'SAFE' proposal in draft-holtman-http-safe-01.txt have been removed. The 'SAFE' proposal will proceed separately. Additional minor edits have been made in response to earlier discussion on the HTTP-WG mailing list. 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 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.2 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 [2] 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 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 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 [2], 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.3 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.4 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.5 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.6 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.7 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. 5 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. 6 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. 7 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. 8 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. 9 Alternatives to the UA-Hint header There have been no alternatives discussed for the directives described in this proposal. 10 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 [2]. 10 References [1] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, HTTP Working Group, January 1997. [2] 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: March 15, 1998