One document matched: 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
| PAFTECH AB 2003-2026 | 2026-04-24 14:07:44 |