4c4 < Expires: September 21, 1997 March 21, 1997 --- > Expires: March 15, 1998 September 16, 1997 9c9 < draft-ietf-http-uahint-00.txt --- > draft-ietf-http-uahint-01.txt 92,94c92,98 < This is the first version of this document. Using different syntax, < it encompasses the functionality described in < draft-holtman-http-safe-01.txt. --- > 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. 107,153c111 < 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 --- > 3.1 Sensitive Application Protection 175c133 < 3.3 History List Presentation Control --- > 3.2 History List Presentation Control 188c146 < Header" released by Holtman and Kaphan in July 1995 [3] describes the --- > Header" released by Holtman and Kaphan in July 1995 [2] describes the 244,290c202 < 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 --- > 4.2 Histage directive 298,302c210,213 < 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. --- > 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. 304c215 < As described in Holtman and Kaphan [3], this directive introduces a --- > As described in Holtman and Kaphan [2], this directive introduces a 310c221 < 4.4 Histinact directive --- > 4.3 Histinact directive 338c249 < 4.5 Histdist directive --- > 4.4 Histdist directive 360c271 < 4.6 Histmode directive --- > 4.5 Histmode directive 448c359 < 4.7 Diskbuff directive --- > 4.6 Diskbuff directive 471c382 < 4.8 Target directive --- > 4.7 Target directive 487c398 < 4.9 Caching Implications --- > 5 Caching Implications 500c411 < 4.10 Future Extensions --- > 6 Future Extensions 512c423 < 5 Smooth upgrade path --- > 7 Smooth upgrade path 529c440 < 6 About syntax --- > 8 About syntax 537c448 < 7 Alternatives to the UA-Hint header --- > 9 Alternatives to the UA-Hint header 539,601c450,451 < 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: < <
< ... <
. < < 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. --- > There have been no alternatives discussed for the directives described > in this proposal. 604c454 < 8 Security considerations --- > 10 Security considerations 626,628c476 < "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. --- > "Problems with the Expires Header [2]. 636,640c484 < [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", --- > [2] Holtman et al, "Problems with the Expires Header", 653c497 < Expires: September 21, 1997 --- > Expires: March 15, 1998 655d498 <  \ No newline at end of file