idnits 2.17.1 draft-holtman-http-safe-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 233 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 1997) is 9768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2068 (ref. '1') (Obsoleted by RFC 2616) -- Unexpected draft version: The latest known version of draft-ietf-html-i18n is -04, but you're referring to -05. ** Downref: Normative reference to an Historic draft: draft-ietf-html-i18n (ref. '2') Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group Koen Holtman, TUE 2 Internet-Draft 3 Expires: January 29, 1998 July 29, 1997 5 The Safe Response Header Field 7 draft-holtman-http-safe-02.txt 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by 19 other documents at any time. It is inappropriate to use 20 Internet-Drafts as reference material or to cite them other 21 than as "work in progress". 23 To learn the current status of any Internet-Draft, please 24 check the "1id-abstracts.txt" listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za 26 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 27 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 28 West Coast). 30 Distribution of this document is unlimited. Please send 31 comments to the HTTP working group at 32 . Discussions of the working 33 group are archived at 34 . General 35 discussions about HTTP and the applications which use HTTP 36 should take place on the mailing list. 38 ABSTRACT 40 This document proposes a HTTP response header field called Safe, 41 which can be used to indicate that repeating the corresponding POST 42 request is safe. Such an indication will allow user agents to 43 present services which use safe POSTs in a more user-friendly way. 44 Improving the user-friendliness of safe POSTs is considered 45 important, because web internationalization will depend for a large 46 part on the use of safe POSTs. 48 1 Introduction 50 This document proposes a HTTP response header field called Safe, 51 which can be used to indicate that repeating the corresponding POST 52 request is safe. Such an indication will allow user agents to 53 present services which use safe POSTs in a more user-friendly way. 54 Improving the user-friendliness of safe POSTs is considered 55 important, because web internationalization will depend for a large 56 part on the use of safe POSTs. 58 2 Background 60 According to Section 9.1.1 (Safe Methods) of the HTTP/1.1 draft 61 specification [1], POST requests are assumed to be `unsafe' by 62 default. `Unsafe' means `causes side effects for which the user will 63 be held accountable'. 65 If the POST request is unsafe, explicit user confirmation is 66 necessary before the request is repeated. User agents will repeat 67 POST requests when the user presses the RELOAD button while a POST 68 result is displayed, or when the history function is used to 69 redisplay a POST result which is no longer in the history buffer. 71 The necessary confirmation dialog often takes the form of a `repost 72 form data?' dialog box. The dialog is confusing to many users, and 73 slows down navigation in any case. 75 In theory, if the repeated POST request is safe, the user-unfriendly 76 confirmation dialog can be omitted. However, up till now, HTTP has 77 no mechanism by which agents can tell if POST requests are safe. 78 This proposal adds such a mechanism. 80 Many content authors have managed to avoid the confirmation dialog 81 problem by using GETs for form submission instead of safe POSTs. 82 However, this escape is not possible for forms 84 a) which are (sometimes) used to submit large amounts of data 85 b) which are (sometimes) used to submit data in a charset other 86 than ISO-8859-1. 88 Case b) will be the increasingly common; web internationalization [2] 89 makes it necessary to use the POST method for form submission. 91 Note: Actually, according to the authors of [2], web 92 internationalization makes it necessary to use requests which 93 request bodies. This rules out the use of the only methods which 94 are safe under HTTP/1.1: GET and HEAD. A new GET-WITH-BODY method 95 could be defined, but it would be unsafe by default under HTTP/1.1, 96 so GET-WITH-HEAD would also need something like the Safe header. 98 It is therefore considered important to eliminate the unnecessary 99 confirmation dialogs for safe POSTs as soon as possible. They are a 100 counter-incentive to the upgrading of GET based forms services (like 101 search engines) to internationalized POST based forms services. 103 3 The Safe response header 105 This header is proposed as an addition to the HTTP/1.x suite. 107 The Safe response header field indicates whether repeating the 108 request in the corresponding request message is safe in the sense of 109 Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1]. 111 Safe = "Safe" ":" safe-nature 112 safe-nature = "yes" | "no" 114 An example of the field is: 116 Safe: yes 118 If the Safe header field is absent in the response, the corresponding 119 request must be considered unsafe, unless it is a GET or HEAD 120 request. GET and HEAD requests are safe by definition, user agents 121 must ignore a `Safe: no' header field in GET and HEAD responses. 123 Note: User agents can use the received information about safety 124 when repeating an earlier request. If the repeating the request 125 is known to be safe, the request can be repeated automatically 126 without asking for user confirmation. 128 4 Smooth upgrade path 130 That the Safe header provides a smooth upgrade path; if a service 131 switches from GETs to safe POSTs, existing browsers will still be 132 able to access the service. Its use requires little re-coding effort 133 for service authors and user agent authors, and is optional in any 134 case. 136 5 About syntax 138 This document mainly intends to recommend a _mechanism_; the syntax 139 of the corresponding header is considered less important. One 140 alternative to the addition of a Safe header would be the addition of 141 a `safe' response directive to the Cache-Control header. 143 6 Alternatives to the Safe header 145 A number of alternative ways to solve the confirmation dialog problem 146 have been proposed. These alternative solutions would make the 147 introduction of the Safe header unnecessary. 149 6.1 GET-WITH-BODY 151 If a new HTTP/1.x GET-WITH-BODY is defined, one would not need the 152 Safe header anymore, one could simply define GET-WITH-BODY as always 153 safe. However, it has been shown that some ugly extensions to the 154 HTML form syntax would be needed to provide the same level of 155 downwards compatibility with existing browsers that Safe can provide, 156 for example 158
159 .... 160
. 162 One could say that a GET-WITH-BODY manages to keep HTTP clean at the 163 cost of adding extensions to HTML. The author of this draft prefers 164 to keep HTML clean by adding the Safe extension to HTTP. 166 Note that the Safe header does not block the introduction of a 167 GET-WITH-BODY in the long run. 169 6.2 Link 171 The need for a confirmation dialog can also be eliminated by offering 172 the user agent an alternative to resubmitting the POST request 173 altogether. A POST result could for example have a Link header which 174 would contain an URL from which the result can be retrieved again 175 with a GET request. However, this Link URL cannot be very long: it 176 it were too long, request would fail due to user agent, proxy, or 177 origin server limitations. This length restriction would make the 178 Link solution hard to use in the general case. 180 6.3 Conclusion 182 The Safe header seems to be the best solution in the current 183 framework. Though the existence of alternative solutions like the 184 ones above has been asserted, the author of this draft has not seen 185 any work on getting alternative solutions standardized. 187 The Safe header would eliminate a counter-incentive to web 188 internationalization, and the author feels that these 189 counter-incentives need to be eliminated as soon as possible. It is 190 therefore proposed to introduce the Safe header into HTTP/1.x without 191 undue delay. 193 The counter-incentive can be thought of as an interoperability 194 problem between HTTP/1.1 [1] and [2]. These documents currently both 195 have the Proposed Standard status. It may be possible to add the 196 Safe header to [1] before it goes to Draft Standard. 198 7 Security considerations 200 This proposal adds no new HTTP security considerations. 202 8 References 204 [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 205 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 206 2068, HTTP Working Group, January, 1997. 208 [2] Yergeau et al, Internationalization of the Hypertext Markup 209 Language, Internet-Draft draft-ietf-html-i18n-05.txt, Network 210 Working Group, August 7, 1996 212 9 Author's address 214 Koen Holtman 215 Technische Universiteit Eindhoven 216 Postbus 513 217 Kamer HG 6.57 218 5600 MB Eindhoven (The Netherlands) 219 Email: koen@win.tue.nl 221 Expires: January 29, 1998