idnits 2.17.1 draft-cohen-http-305-306-responses-00.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-24) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 66: '... The request SHOULD be accompanied b...' RFC 2119 keyword, line 72: '... MUST be accompanied by a 'Location'...' RFC 2119 keyword, line 75: '...in the response, the client SHOULD use...' RFC 2119 keyword, line 84: '...06 response code MUST be accompanied b...' RFC 2119 keyword, line 93: '... then it SHOULD be included in the 5...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 140 has weird spacing: '... client does ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Both the 305 and 306 response codes are HOP by HOP. A proxy server MUST not forward a 305 or 306 respose code (unless it generated the 306). -- 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 (5 December 1996) is 10002 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group Josh Cohen 3 Internet-Draft Netscape Communications Corp. 4 5 December 1996 6 HTTP/1.1 305 and 306 Response Codes 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The HTTP/1.1 RFC specifies a response code '305 Use Proxy' which is 31 intended to cause a client to retry the request using a specified 32 proxy server. This functionality is important, but underspecified in 33 the current spec. The spec does not specify for how long or which 34 URLs the redirect applies to, or how proxies can deal with or 35 generate similar responses. This draft proposes a specification for 36 both the 305 response and a new response, "306 Switch Proxy". 38 Summary 40 1.0 Response Codes 42 1.1 305 Use Proxy 43 1.2 306 Switch Proxy 44 1.3 506 Redirection Failed 46 2.0 Headers 48 2.1 Set-proxy: 49 2.2 Location: 51 3.0 Methods 53 3.1 OPTIONS 55 4.0 Operational Constraints 57 5.0 Notes 59 1.0 Response Codes 61 1.1 305 Use Proxy 63 The 305 is generated by an origin server to indicate that the client, 64 or proxy, should use a proxy to access the requested resource. 66 The request SHOULD be accompanied by a 'Set-proxy' response header 67 indicating what proxy is to be used. The client will parse the 'Set- 68 proxy' header as defined below to decide how long, for what URLs it 69 should use the specified proxy. 71 If the 305 response is not accompanied by a 'Set-proxy' header, it 72 MUST be accompanied by a 'Location' header. The 'Location' header 73 will specify a URL to the proxy. 75 If both headers are present in the response, the client SHOULD use 76 the 'Set-proxy' header only. 78 1.2 306 Switch Proxy 80 The 306 response is generated by a proxy server to indicate that the 81 client or proxy should use the information in the accompanying 'Set- 82 proxy' header to choose a proxy for subsequent requests. 84 The 306 response code MUST be accompanied by the 'Set-proxy' response 85 header. The client or proxy will parse the 'Set-proxy' header to 86 determine which proxy to use, how long to use it, and for which URLs 87 to use it. 89 1.3 506 Redirection Failed 91 The 506 response is returned when a redirection fails or is refused 92 by a proxy or client. If the redirection response included a body, 93 then it SHOULD be included in the 506 response. 95 2.0 Headers 97 2.1 'Set-proxy' Response Header 99 The 'Set-proxy' header is defined as: 101 Set-proxy: "Set-proxy" ":" 1( 102 action #(parameters) 103 ) 105 parameters = #( ( "scope" "=" scopePattern ) | 106 ( proxyURI "=" URI ) | 107 lifetime ) 109 lifetime = ( "seconds" "=" integer ) 110 | ( "hits" "=" integer ) 112 action = ( "DIRECT" 113 | "IPL" 114 | "SET" ) 115 ) ";" 117 scopePattern = "*" | "-" | URIpattern 119 An example header: 120 Set-proxy: SET ; proxyURI = "http://proxy.me.com:8080/", 121 scope="http://", seconds=5 123 action 125 The first item, "action" specifies the type or mode of the change. 126 Possible modes are: 128 DIRECT 129 Attempt to connect directly, with no proxy 131 IPL 132 Initial Program Load, the client or proxy should attempt to revert 133 back to its default or initial proxy setting. This is meant to 134 instruct a client to re-fetch its proxy configuration, or PAC file. 135 When set, the accompanying scope field MUST be "*" A client receiv- 136 ing this response SHOULD prompt the user for confirmation. 138 If accompanied by a 'proxyURI' parameter, a proxy or client MAY use 139 the value as a URL containing a configuration to retrieve. If a 140 client does so, it MUST prompt the user for confirmation. 142 SET 143 Set to parameter "proxyURI". The client should use the URL speci- 144 fied for "proxyURI" as the proxy. If the SET mode is specified, the 145 parameter, "proxyURI", MUST be present. 147 Scope 149 Scope refers to a URI prefix pattern that specifies which URIs are 150 subject to this header setting. URIs should be matched against the 151 scope with this rule : 153 The scope "*" means all requests 154 The scope "-" means this EXACT URL ONLY 156 Otherwise, the URL is compared with the scope after it is: 158 * truncated to the length of the scope 160 * domain names are set in reverse order. 162 For example: 164 scope = "http://com.foo.www/services/" 166 URL "http://www.foo.com/services/express/2day.html" 167 transformed: "http://com.foo.www/services/express/" (MATCH) 169 Another example: 171 scope = "http://com.ups/" URL "http://www.ups.com/" (MATCH) 172 URL "http://www.fedex.com/" (FAIL) 174 The lifetime parameter specifies how long the specified proxy 175 should be used. If lifetime is specified as "seconds" then the 176 proxy setting remains in effect for 'integer' seconds. If lifetime 177 is specified in 'hits' then the proxy setting remains in effect for 178 'integer' transactions. 180 2.2 Location Header 182 In the original HTTP/1.1 spec, the 'Location' header was used to 183 indicate the proxy setting. Its use is DEPRECATED by the 'Set- 184 proxy' header in the context of a 305 response. All new implementa- 185 tions MUST send the Set-proxy header. Implementations MAY send the 186 'Location' header so as to allow backward compatibility. 188 If the 'Location' header is specified, it should contain a URI of 189 the proxy. If the Set-proxy header is not specified, the client 190 should use this proxy for just one request, and only for the origi- 191 nally requested exact URL. 193 3.0 Methods 195 A client or proxy receiving a 305 or 306, should use the OPTIONS 196 method to determine if the server or proxy it is talking to actu- 197 ally is an HTTP/1.1 server supporting 305 and 306 responses. 199 4.0 Operational Constraints 201 * Both the 305 and 306 response codes are HOP by HOP. A proxy server 202 MUST not forward a 305 or 306 respose code (unless it generated the 203 306). 205 * A webserver MUST NOT send a 306 response under any circumstances 207 * A proxy server MUST NOT generate a 305 response. 209 * A client or proxy SHOULD NOT accept a 306 from a proxy that it 210 learned of via a 305 response code. 212 * A client or proxy MAY maintain state and allow a lifetime to extend 213 beyond a session or restart. 215 * A 'Set-proxy: IPL' SHOULD override any previous 'Set-proxy' header. 217 * A 305 or 306 response MAY contain a body containing an explanation 218 of the redirect for clients which do not understand the redirect 220 * In the absence of any parameter, the following defaults should be 221 used: 223 lifetime = this transaction only 224 scope = this exact URL only 226 * When receiving a 305 response, the client or proxy will enforce the 227 following rule with respect to the scope. 229 The scope specified must be more restrictive than the transformed 230 URL in question. 232 Example: (in order of restrictiveness) 234 http://com.ups.www/services/express/1day.html ( most restrictive) 235 http://com.ups.www/ (all requests for only www.ups.com ) 236 http://com.ups ( all requests for ups.com ) 237 http:// ( for all http requests ) 239 * ( all requests ) 241 If the scope returned with a 305 response is less restrictive than 242 the requested URL, the client MUST prompt the user for confirmation 243 before accepting the new proxy setting. 245 * Since HTTP/1.0 proxies may unknowingly forward a 305 or 306 246 response code that was generated maliciously or in good faith, the 247 client must attempt to ascertain if the proxy with which it is 248 directly communicating is HTTP/1.1 and if it supports the 'Set- 249 proxy' header. To determine this, the client or proxy should use 250 the OPTIONS method to make a request check for this feature. 252 Security Considerations 254 Great care should be taken when implementing client side actions 255 based on the 305 or 306. Since older proxies may unknowingly for- 256 ward either of these reponses, clients should be prepared to check 257 the validity. 259 * Please read the section 'Operational Constraints' 261 * A client or proxy MUST NOT accept a 305 response from a proxy. 263 * A client or proxy MUST NOT accept a 306 response from an origin 264 server. 266 * When receiving a 306 response from a proxy, the client MUST verify 267 that the proxy supports the 306 response with a METHODS request. 269 5.0 Notes 271 Further specification is needed to define exactly how to use 272 METHODs, or another mechanism to determin if set-proxy is sup- 273 ported. 275 Author's Address 277 Josh Cohen 278 Netscape Communications Corporation 279 501 E. Middlefield Rd 280 Mountain View, CA 94043 281 Phone (415) 937-4157 282 EMail: josh@netscape.com