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


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
        <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 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:

     <form action="..." method=post preferred_method=get-with-body>
     ...
     </form>.

   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

