< draft-yevstifeyev-http-headers-not-recognized-11.txt   draft-yevstifeyev-http-headers-not-recognized-08.txt >
INTERNET-DRAFT Mykyta Yevstifeyev
Intended Status: Experimental December 12, 2010
Expires: June 15, 2011
INTERNET-DRAFT M. Yevstifeyev 'Headers-Not-Recognized' HTTP Header Field
Intended Status: Experimental January 8, 2011 <draft-yevstifeyev-http-headers-not-recognized-08>
Expires: July 12, 2011
HTTP 'Headers-Not-Recognized' Header Field
<draft-yevstifeyev-http-headers-not-recognized-11>
Abstract Abstract
This document defines mechanism which allows HTTP hosts to notify This document defines mechanism which allows HTTP servers to notify
another hosts about not supported header fields - 'Headers-Not- clients about not recognized or not proceed headers - 'Headers-Not-
Recognized' HTTP header field. Recognized' HTTP Response header.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 21
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Conformance Criteria . . . . . . . . . . . . . . . . . 3 1.2.1. Conformance Criteria . . . . . . . . . . . . . . . . . 3
1.2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . 3 1.2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . 3
1.2.3. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.2.3. Terminology . . . . . . . . . . . . . . . . . . . . . 3
2. Technical Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2. Technical Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Model of Work . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Model of Work . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . . . 5 5. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
HTTP is one of the most widely-used protocols in the Internet. One HTTP is one of the most widely-used protocols in the Internet. One of
of the things which made it so popular is extensibility. One can the things which made it so popular is extensibility. One can easily
easily add any header field to the HTTP message. However, all hosts add any header to the HTTP message. However, servers are not able to
are not able to support all the header fields. Generally, if a it support all the HTTP headers. Generally, if a server does not
host does not support the header field, it is simply ignored. The recognize the header, it simply ignores it. The client is not
another side of exchange is not notified about not processed header notified about not processed headers.
fields.
This document proposes mechanism which allows HTTP hosts to notify This document proposes mechanism which allows servers to notify
another hosts about not recognized header fields. clients about not processes or not recognized headers.
The proposal is to send an HTTP message with definite header field to The proposal is to send a response with definite header field to the
the host if one or more header fields of its message are not client if one or more headers of request were not processed. This
supported. This document defines 'Headers-Not-Recognized' HTTP header document defines 'Headers-Not-Recognized' header field to be used in
field to be used in such occasion. such occasion.
1.2. Conventions 1.2. Conventions
HTTP refers to protocol, defined in RFC 2616 [RFC2616]
1.2.1. Conformance Criteria 1.2.1. Conformance Criteria
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2.2. Syntax Notation 1.2.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
The construction <n>#<m>element is used as defined in RFC 2616 The construction <n>#<m>element is used as defined in RFC 2616
[RFC2616], Section 2.1. [RFC2616], Section 2.1.
1.2.3. Terminology 1.2.3. Terminology
HTTP refers to protocol, defined in RFC 2616 [RFC2616] The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
The terms client, server, proxy, gateway and tunnel have the same 1.3).
meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).
The term host means client or server.
2. Technical Overview 2. Technical Overview
2.1 Model of Work 2.1 Model of Work
If the HTTP host receives HTTP message which contains some header If a server receives request with unknown (for it) headers, it is
fields which are not supported by it, it is RECOMMENDED for it to RECOMMENDED that it sends a response with 'Headers-Not-Recognized'
include the Headers-Not-Recognized header field in the response to headers field. Information about what headers were not recognized
the host that sent message with not supported header fields. MUST be put into this header. If a client receives such a response,
Information about not supported header fields is to be put in the it is RECOMMENDED that it avoids sending requests with headers
'Headers-Not-Recognized' header field following the rules of Section mentioned in the 'Headers-Not-Recognized' header field or tries to
2.2 of this document. The 'Headers-Not-Recognized' header field MUST change them so that the server recognize them.
contain information only about not supported header fields - i.e.
header fields which are not able to be processed anyway. It MUST NOT
contain information about header fields, which are partly supported,
whose entity cannot be processed while the header field is supported
at all, etc.
When HTTP host receives HTTP message with Headers-Not-Recognized
header field, it is RECOMMENDED that it avoids sending messages with
header fields with mentioned in it names to source (for such message)
host.
Intermediate systems (also called middle-boxes), such as proxies, 'Headers-Not-Recognized' is a response HTTP header.
tunnels, gateways, etc. SHALL transfer the messages with 'Headers-
Not-Recognized' header field to the destination host without changing
the entity of this header field if the not supported header field was
present in the initial HTTP message (i. e. message which intermediate
system received before transferring it to destination host), but
SHALL omit it if Headers-Not-Recognized header field's entity
concerns only to header fields added to initial message by middle-
box. If the aforementioned header field concerns added header fields
partly, middle-box SHALL change the entity so that it concerns only
initial message header field.
2.2 Syntax 2.2 Syntax
'Headers-Not-Recognized' header field has the following format: 'Headers-Not-Recognized' header field has the following format:
headers_not_recognized = 1#header_name headers_not_recognized = 1#header_name
header_name = 1*VCHAR header_name = token ;name of not recognized header
token = <as defined in RFC 2616 [RFC2616]>
3. IANA Considerations 3. IANA Considerations
The permanent message header field registry should be updated with The permanent message header field registry should be updated with
the following registration (see [RFC3864]): the following registration:
Header field name Header field name: Headers-Not-Recognized
Headers-Not-Recognized
Applicable protocol Applicable protocol: http
http
Status Status: experimental
experimental
Specification document Specification document: RFC xxxx
RFC xxxx
[RFC Editor: replace xxxx with assigned RFC number] [RFC Editor: replace xxxx with assigned RFC number]
[Note: This registration should take place at
http://www.iana.org/assignments/message-headers/perm-headers.html Note: This registration should take place at
This note is to be deleted upon publication.] http://www.iana.org/assignments/message-headers/perm-
headers.html
This note MUST be deleted upon publication.
4. Security Considerations 4. Security Considerations
This extension to HTTP is not believed to add any additional security This extension to HTTP is not believed to add any additional security
concerns not already present in RFC 2616 [RFC2616]. concerns not already present in RFC 2616 [RFC2616].
5. Normative References 5. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008. 2008.
Author's Addresses Author's Addresses
Mykyta Yevstifeyev Mykyta Yevstifeyev
8 Kuzovkov St., flat 25
Kotovsk, Ukraine Kotovsk, Ukraine
EMail: evnikita2@gmail.com EMail: evnikita2@gmail.com
 End of changes. 21 change blocks. 
75 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35