2004/id/draft-ietf-http-uahint-01.txt


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
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> 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
