idnits 2.17.1 draft-yevstifeyev-http-headers-not-recognized-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 8, 2011) is 4851 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Yevstifeyev 3 Intended Status: Experimental January 8, 2011 4 Expires: July 12, 2011 6 HTTP 'Headers-Not-Recognized' Header Field 7 9 Abstract 11 This document defines mechanism which allows HTTP hosts to notify 12 another hosts about not supported header fields - 'Headers-Not- 13 Recognized' HTTP header field. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2.1. Conformance Criteria . . . . . . . . . . . . . . . . . 3 57 1.2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . 3 58 1.2.3. Terminology . . . . . . . . . . . . . . . . . . . . . 3 59 2. Technical Overview . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1 Model of Work . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5. Normative References . . . . . . . . . . . . . . . . . . . . . . 5 65 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 1.1. Motivation 71 HTTP is one of the most widely-used protocols in the Internet. One 72 of the things which made it so popular is extensibility. One can 73 easily add any header field to the HTTP message. However, all hosts 74 are not able to support all the header fields. Generally, if a it 75 host does not support the header field, it is simply ignored. The 76 another side of exchange is not notified about not processed header 77 fields. 79 This document proposes mechanism which allows HTTP hosts to notify 80 another hosts about not recognized header fields. 82 The proposal is to send an HTTP message with definite header field to 83 the host if one or more header fields of its message are not 84 supported. This document defines 'Headers-Not-Recognized' HTTP header 85 field to be used in such occasion. 87 1.2. Conventions 89 1.2.1. Conformance Criteria 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 1.2.2. Syntax Notation 97 This specification uses the Augmented Backus-Naur Form (ABNF) 98 notation of [RFC5234]. 100 The construction #element is used as defined in RFC 2616 101 [RFC2616], Section 2.1. 103 1.2.3. Terminology 105 HTTP refers to protocol, defined in RFC 2616 [RFC2616] 107 The terms client, server, proxy, gateway and tunnel have the same 108 meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3). 110 The term host means client or server. 112 2. Technical Overview 114 2.1 Model of Work 116 If the HTTP host receives HTTP message which contains some header 117 fields which are not supported by it, it is RECOMMENDED for it to 118 include the Headers-Not-Recognized header field in the response to 119 the host that sent message with not supported header fields. 120 Information about not supported header fields is to be put in the 121 'Headers-Not-Recognized' header field following the rules of Section 122 2.2 of this document. The 'Headers-Not-Recognized' header field MUST 123 contain information only about not supported header fields - i.e. 124 header fields which are not able to be processed anyway. It MUST NOT 125 contain information about header fields, which are partly supported, 126 whose entity cannot be processed while the header field is supported 127 at all, etc. 129 When HTTP host receives HTTP message with Headers-Not-Recognized 130 header field, it is RECOMMENDED that it avoids sending messages with 131 header fields with mentioned in it names to source (for such message) 132 host. 134 Intermediate systems (also called middle-boxes), such as proxies, 135 tunnels, gateways, etc. SHALL transfer the messages with 'Headers- 136 Not-Recognized' header field to the destination host without changing 137 the entity of this header field if the not supported header field was 138 present in the initial HTTP message (i. e. message which intermediate 139 system received before transferring it to destination host), but 140 SHALL omit it if Headers-Not-Recognized header field's entity 141 concerns only to header fields added to initial message by middle- 142 box. If the aforementioned header field concerns added header fields 143 partly, middle-box SHALL change the entity so that it concerns only 144 initial message header field. 146 2.2 Syntax 148 'Headers-Not-Recognized' header field has the following format: 150 headers_not_recognized = 1#header_name 151 header_name = 1*VCHAR 153 3. IANA Considerations 155 The permanent message header field registry should be updated with 156 the following registration (see [RFC3864]): 158 Header field name 159 Headers-Not-Recognized 161 Applicable protocol 162 http 164 Status 165 experimental 167 Specification document 168 RFC xxxx 170 [RFC Editor: replace xxxx with assigned RFC number] 171 [Note: This registration should take place at 172 http://www.iana.org/assignments/message-headers/perm-headers.html 173 This note is to be deleted upon publication.] 175 4. Security Considerations 177 This extension to HTTP is not believed to add any additional security 178 concerns not already present in RFC 2616 [RFC2616]. 180 5. Normative References 182 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, March 1997. 185 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 186 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 187 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 189 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 190 Procedures for Message Header Fields", BCP 90, RFC 3864, 191 September 2004. 193 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 194 Syntax Specifications: ABNF", STD 68, RFC 5234, January 195 2008. 197 Author's Addresses 199 Mykyta Yevstifeyev 200 Kotovsk, Ukraine 202 EMail: evnikita2@gmail.com