draft-ietf-http-uahint-00.txt   draft-ietf-http-uahint-01.txt 
Internet-Draft David Morris, BSL Internet-Draft David Morris, BSL
HTTP Working Group HTTP Working Group
Expires: September 21, 1997 March 21, 1997 Expires: March 15, 1998 September 16, 1997
The User Agent Hint Response Header The User Agent Hint Response Header
draft-ietf-http-uahint-00.txt draft-ietf-http-uahint-01.txt
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 88 skipping to change at line 88
History-List: Application designers have long been frustrated over History-List: Application designers have long been frustrated over
their lack of control over the user agent's handling of the history their lack of control over the user agent's handling of the history
list. This UA-Hint header proposed by this document specifies list. This UA-Hint header proposed by this document specifies
a number of directives which can be used to insure expected a number of directives which can be used to insure expected
behavior of the user's view of the application. Optional handling behavior of the user's view of the application. Optional handling
includes setting a maximum time for retention of a response in includes setting a maximum time for retention of a response in
the History-List and exclusion of responses from the history list. the History-List and exclusion of responses from the history list.
1.1 Revision history 1.1 Revision history
This is the first version of this document. Using different syntax, This is the first revision of this document. As a result of
it encompasses the functionality described in working group direction, all aspects of the 'SAFE' proposal in
draft-holtman-http-safe-01.txt. 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 2 Notational Conventions and Generic Grammar
This document follows the conventions described in Section 2 of the This document follows the conventions described in Section 2 of the
HTTP/1.1 specification [1]. HTTP/1.1 specification [1].
3 Background 3 Background
The motivation for the specific directives described in this The motivation for the specific directives described in this
proposal are presented in detail in this section. proposal are presented in detail in this section.
3.1 Safe Request with Content Body 3.1 Sensitive Application Protection
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 There have been a number of posts to the www-security mailing list
over the past several months from web application developers over the past several months from web application developers
concerned about the security aspects of access to concerned about the security aspects of access to
their applications by user's of shared browsers. There are several their applications by user's of shared browsers. There are several
issues which have been raised: issues which have been raised:
a) Re-invoking prior login screens from the History List (assuming a) Re-invoking prior login screens from the History List (assuming
that the application implements its own mechanism beyond that the application implements its own mechanism beyond
WWW-Authenticate) WWW-Authenticate)
skipping to change at line 170 skipping to change at line 128
Section 13.13 (History Lists) of the HTTP/1.1 specification [1], Section 13.13 (History Lists) of the HTTP/1.1 specification [1],
describes the History List as different from a cache but does not describes the History List as different from a cache but does not
provide any mechanism by which the server can control the History provide any mechanism by which the server can control the History
List. As a result, the protections desired by application authors List. As a result, the protections desired by application authors
concerned with the issues described in this section are almost concerned with the issues described in this section are almost
impossible to achieve. We are aware of one home banking application impossible to achieve. We are aware of one home banking application
which depended on the observed behavior of user agents to not retain which depended on the observed behavior of user agents to not retain
the content of error responses in their History List backing store. the content of error responses in their History List backing store.
3.3 History List Presentation Control 3.2 History List Presentation Control
In some applications, it is useful to include the user agent's In some applications, it is useful to include the user agent's
History List in the overall user/application interaction paradigm. History List in the overall user/application interaction paradigm.
This surfaces in instructions like error messages which direct the This surfaces in instructions like error messages which direct the
user to return to the previous page and correct their input. user to return to the previous page and correct their input.
Unfortunately, the evolving defacto standard is unpredictable Unfortunately, the evolving defacto standard is unpredictable
behavior from an application perspective. Recent observations behavior from an application perspective. Recent observations
suggest that each user agent vendor uses a different set of suggest that each user agent vendor uses a different set of
heuristics to determine the content of the History List and when a heuristics to determine the content of the History List and when a
response is refreshed or replaced by a subsequent response received response is refreshed or replaced by a subsequent response received
later in the user's session. These heuristics , often seem different later in the user's session. These heuristics , often seem different
in each version of a product. The paper "Problems With the Expires in each version of a product. The paper "Problems With the Expires
Header" released by Holtman and Kaphan in July 1995 [3] describes the Header" released by Holtman and Kaphan in July 1995 [2] describes the
basic issues and suggests a number of alternative approaches. basic issues and suggests a number of alternative approaches.
The History List is a resource which logically belongs to the user 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 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 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 actions and results. The majority of web content is static from a
navigational perspective. That is, the user navigates by clicking navigational perspective. That is, the user navigates by clicking
links and is presented with results which reflect the navigation. links and is presented with results which reflect the navigation.
While the results may differ based on external factors, from the While the results may differ based on external factors, from the
user's perspective the results are equivalent. user's perspective the results are equivalent.
skipping to change at line 238 skipping to change at line 196
; case insensitive ; case insensitive
hint-value = *1( token | quoted-string ) hint-value = *1( token | quoted-string )
hint-dirparm = *1( token "=" ) hint-value hint-dirparm = *1( token "=" ) hint-value
This document proposes several specific hint-directives below, but This document proposes several specific hint-directives below, but
this syntax is intended to accommodate many possible future extension this syntax is intended to accommodate many possible future extension
syntaxes. syntaxes.
4.2 Resubmit directive 4.2 Histage 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 The Histage directive may be used to specify how long a response may
be retained in the History List prior to deletion or refresh. be retained in the History List prior to deletion or refresh.
Histage = "Histage" "=" 1*digit ; seconds since receipt Histage = "Histage" "=" 1*digit ; seconds since receipt
A Histage value of zero (0) requires refresh each time the response A Histage value of zero (0) requires refresh each time the response
would be shown as a result of History List navigation. Once the would be shown as a result of History List navigation. Once the
Histage interval has elapsed, the response must be refreshed under Histage interval has elapsed, the response must be refreshed before it
the terms of the Resubmit directive before it is shown to the user. is shown to the user. See the Histmode directive below for preferred
See the Histmode directive below for preferred methods for omitting methods for omitting responses from the History List.
responses from the History List.
As described in Holtman and Kaphan [3], this directive introduces a As described in Holtman and Kaphan [2], this directive introduces a
separate notion of History List expiration from the notion of cache separate notion of History List expiration from the notion of cache
expiration. Thus, the application designer can allow a document to expiration. Thus, the application designer can allow a document to
be immediately expired from a cache perspective, but retained as be immediately expired from a cache perspective, but retained as
a stable reference in the History List. a stable reference in the History List.
4.4 Histinact directive 4.3 Histinact directive
The Histinact directive may be used to specify how long a response The Histinact directive may be used to specify how long a response
may be retained in the History List prior to deletion or refresh may be retained in the History List prior to deletion or refresh
expressed in terms of user agent activity. expressed in terms of user agent activity.
Histinact = "Histinact" "=" 1*digit ; seconds since user Histinact = "Histinact" "=" 1*digit ; seconds since user
; activity ; activity
This directive is similar to Histage except that expiration is based This directive is similar to Histage except that expiration is based
on the amount of time since the last user interaction with the on the amount of time since the last user interaction with the
skipping to change at line 332 skipping to change at line 243
from the active view. from the active view.
This directive is intended to provide a control mechanism which This directive is intended to provide a control mechanism which
reduces the exposure of sensitive information when a user fails reduces the exposure of sensitive information when a user fails
to secure an active user agent before leaving a work station. to secure an active user agent before leaving a work station.
By watching user activity, the user agent can leave History List By watching user activity, the user agent can leave History List
content available for review for a longer interval using the content available for review for a longer interval using the
activity relative timeout provided by this directive in lieu of activity relative timeout provided by this directive in lieu of
the absolute timeout provided by the Histage directive. the absolute timeout provided by the Histage directive.
4.5 Histdist directive 4.4 Histdist directive
The Histdist directive provides an alternate user behavior model for The Histdist directive provides an alternate user behavior model for
controlling the duration that a response remains active in the controlling the duration that a response remains active in the
History List. History List.
Histdist = "Histdist" "=" 1*digit ; responses after this Histdist = "Histdist" "=" 1*digit ; responses after this
This response will remain active until more than the specified number This response will remain active until more than the specified number
of responses are in the History List after this response. of responses are in the History List after this response.
Examples of usage: Examples of usage:
UA-Hint: histdist=1 UA-Hint: histdist=1
In this case, the response will be active while any response In this case, the response will be active while any response
activated from this response is the next response in the activated from this response is the next response in the
History List. Thus, the user can flip between this response History List. Thus, the user can flip between this response
and the next response, but once they navigate further, this and the next response, but once they navigate further, this
History List entry is deleted. History List entry is deleted.
4.6 Histmode directive 4.5 Histmode directive
The Histmode directive may be used to specify special handling of a The Histmode directive may be used to specify special handling of a
response in the History list. response in the History list.
Histmode = "Histmode" "=" ( "no" | "replace" | "popup" | Histmode = "Histmode" "=" ( "no" | "replace" | "popup" |
| "explicit" ) | "explicit" )
Value interpretation: Value interpretation:
"no" This response SHOULD NOT be represented in the History List. "no" This response SHOULD NOT be represented in the History List.
skipping to change at line 441 skipping to change at line 352
Many applications advise the user of input errors with some Many applications advise the user of input errors with some
kind of temporary window while leaving the original input kind of temporary window while leaving the original input
available for user correction and resubmission. This available for user correction and resubmission. This
directive provides a web facility with similar user directive provides a web facility with similar user
interaction characteristics. Other applications provide a interaction characteristics. Other applications provide a
temporary confirmation message indication an application temporary confirmation message indication an application
completed a request or in the case of safe delete interfaces, completed a request or in the case of safe delete interfaces,
requests user confirmation of their intent. requests user confirmation of their intent.
4.7 Diskbuff directive 4.6 Diskbuff directive
The Diskbuff directive may be used to specify specific storage The Diskbuff directive may be used to specify specific storage
characteristics of a response retained by a user agent in support of characteristics of a response retained by a user agent in support of
its History List or response cache. its History List or response cache.
Diskbuff = "Diskbuff" "=" "no" Diskbuff = "Diskbuff" "=" "no"
If this directive is specified, the user agent MAY NOT use any form If this directive is specified, the user agent MAY NOT use any form
of storage other than virtual memory to retain the response. Prior of storage other than virtual memory to retain the response. Prior
to releasing memory resources used to store this response, they to releasing memory resources used to store this response, they
skipping to change at line 463 skipping to change at line 374
This directive is intended to minimize the possibility that This directive is intended to minimize the possibility that
incorrectly configured shared file systems, operating system memory incorrectly configured shared file systems, operating system memory
dump files, etc. will allow viewing of the response by an dump files, etc. will allow viewing of the response by an
unauthorized individual. unauthorized individual.
The Diskbuff=no directive explicitly overrides the provision in The Diskbuff=no directive explicitly overrides the provision in
section 14.9.2 of the HTTP/1.1 specification [1] which allows a section 14.9.2 of the HTTP/1.1 specification [1] which allows a
History buffer to store a response. History buffer to store a response.
4.8 Target directive 4.7 Target directive
The Target directive is similar in function to the target attribute The Target directive is similar in function to the target attribute
included with recent additions to HTML anchors. included with recent additions to HTML anchors.
Target = "Target" "=" ( token | quoted-string ) Target = "Target" "=" ( token | quoted-string )
The value of this directive logically names a window in which this The value of this directive logically names a window in which this
response should be displayed. If the window already exists, this response should be displayed. If the window already exists, this
response becomes the next response in that window and that window response becomes the next response in that window and that window
is restored and given the focus. If the specified target 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 does not exist, it should be created as a visual and functional clone
of the window from which this request originated. User agents which of the window from which this request originated. User agents which
do not support multiple window should ignore this directive. do not support multiple window should ignore this directive.
4.9 Caching Implications 5 Caching Implications
This proposal is compatible with caching controls as specified by the This proposal is compatible with caching controls as specified by the
HTTP/1.1 specification. Specifically, The UA-Hint response header HTTP/1.1 specification. Specifically, The UA-Hint response header
MUST be included with any response returned from a cache unless a MUST be included with any response returned from a cache unless a
caching directive is present which disables such inclusion. If a caching directive is present which disables such inclusion. If a
re-validate with the origin server included a UA-Hint response re-validate with the origin server included a UA-Hint response
header, the new header should replace the currently cached value for header, the new header should replace the currently cached value for
the current and subsequent requests. the current and subsequent requests.
The value of the UA-Hint header is not interpreted by a cache. The value of the UA-Hint header is not interpreted by a cache.
4.10 Future Extensions 6 Future Extensions
As has been noted, this header is intended to be extensible. As has been noted, this header is intended to be extensible.
Implementers are encouraged to experiment with new values but must be Implementers are encouraged to experiment with new values but must be
aware that success depends on both communicating parties correctly aware that success depends on both communicating parties correctly
interpreting such experiments. To insure correct interpretation and interpreting such experiments. To insure correct interpretation and
avoid conflicts between experiments conducted by different avoid conflicts between experiments conducted by different
organizations, implementers are encouraged to document their organizations, implementers are encouraged to document their
experiments using the IETF draft and RFC process at the earliest experiments using the IETF draft and RFC process at the earliest
possible time in the implementation cycle. possible time in the implementation cycle.
5 Smooth upgrade path 7 Smooth upgrade path
All directives associated with the UA-Hint header are designed to All directives associated with the UA-Hint header are designed to
fail smoothly such that failure of a user agent to recognize and fail smoothly such that failure of a user agent to recognize and
honor and directive will not prevent a user from accessing a service honor and directive will not prevent a user from accessing a service
(using other mechanisms, the service may determine if a user agent (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 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 not). Its use is not required except to achieve the improved user
interface behavior described herein. interface behavior described herein.
In addition, the UA-Hint header does not depend upon the HTTP/1.1 In addition, the UA-Hint header does not depend upon the HTTP/1.1
specification [1], hence it can be implemented by applications specification [1], hence it can be implemented by applications
delivered by any HTTP/1.x compliant server. An HTTP/1.0 user agent delivered by any HTTP/1.x compliant server. An HTTP/1.0 user agent
could choose to implement this proposal prior to being fully could choose to implement this proposal prior to being fully
compliant with HTTP/1.1. compliant with HTTP/1.1.
6 About syntax 8 About syntax
This document mainly intends to recommend a set of mechanisms for This document mainly intends to recommend a set of mechanisms for
improving an application's control over the user's experience. The improving an application's control over the user's experience. The
syntax of the corresponding header is considered less important and syntax of the corresponding header is considered less important and
alternative headers and/or directives would be considered. alternative headers and/or directives would be considered.
7 Alternatives to the UA-Hint header 9 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 There have been no alternatives discussed for the directives described
counter-incentive to web internationalization, and the author feels in this proposal.
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 10 Security considerations
This proposal makes no changes to HTTP which would degrade its This proposal makes no changes to HTTP which would degrade its
security characteristics. Several changes are proposed which if security characteristics. Several changes are proposed which if
applied carefully, will provide additional information security for applied carefully, will provide additional information security for
applications. In summary, these are: applications. In summary, these are:
o All storage of a response on persistent storage can be blocked 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 Representation of a response in the History List can be blocked
o New controls are proposed which limit the duration of time a o New controls are proposed which limit the duration of time a
a response can be retained in the history list. a response can be retained in the history list.
o The UA-Hint header is extensible and could be used to provide o The UA-Hint header is extensible and could be used to provide
additional security controls, block printing, etc. additional security controls, block printing, etc.
9 Acknowledgements 9 Acknowledgements
This specification was influenced by the early discussion of This specification was influenced by the early discussion of
History List difficulties described by Holtman and Kaphan in History List difficulties described by Holtman and Kaphan in
"Problems with the Expires Header [3] and by the earlier IETF "Problems with the Expires Header [2].
draft draft-holtman-http-safe-01.txt from which the bulk of the
text describing the resubmit=safe directive was extracted.
10 References 10 References
[1] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", [1] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC2068, HTTP Working Group, January 1997. RFC2068, HTTP Working Group, January 1997.
[2] Yergeau et al, "Internationalization of the Hypertext Markup [2] Holtman et al, "Problems with the Expires Header",
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. http://www.amazon.com/expires-report.html, July 19, 1995.
11 Author's address 11 Author's address
David Morris David Morris
barili systems limited barili systems limited
10873 W. Estates Drive 10873 W. Estates Drive
Cupertino, CA 95014 Cupertino, CA 95014
Email: dwm@xpasc.com Email: dwm@xpasc.com
Expires: September 21, 1997 Expires: March 15, 1998

 End of changes. 24 change blocks. 
188 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/