< draft-yevstifeyev-http-headers-not-recognized-10.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 December 31, 2010 <draft-yevstifeyev-http-headers-not-recognized-08>
Expires: July 4, 2011
HTTP 'Headers-Not-Recognized' Header Field
<draft-yevstifeyev-http-headers-not-recognized-10>
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 headers - 'Headers-Not-Recognized' clients about not recognized or not proceed headers - 'Headers-Not-
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 3, line 11 skipping to change at page 3, line 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . . . 5 5. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 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 of HTTP is one of the most widely-used protocols in the Internet. One of
the things which made it so popular is extensibility. One can easily the things which made it so popular is extensibility. One can easily
add any header field to the HTTP message. However, all hosts are not add any header to the HTTP message. However, servers are not able to
able to support all the header fields. Generally, if a it host does support all the HTTP headers. Generally, if a server does not
not support the header field, it is simply ignored. The another side recognize the header, it simply ignores it. The client is not
of exchange is not notified about not processed header fields. notified about not processed headers.
This document proposes mechanism which allows HTTP hosts to notify This document proposes mechanism which allows servers to notify
another hosts about not recognized headers. clients about not processes or not recognized headers.
The proposal is to send a message with definite header field to the The proposal is to send a response with definite header field to the
host if one or more header fields of its request are not supported. client if one or more headers of request were not processed. This
This document defines 'Headers-Not-Recognized' HTTP header field to document defines 'Headers-Not-Recognized' header field to be used in
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 message with
this header field) host or tries to change them so that hat host is
able to recognize and process them.
Intermediate systems (also called middle-boxes), such as proxies, 'Headers-Not-Recognized' is a response HTTP header.
tunnels, gateways etc. MUST 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 request (i. e. request which intermediate
system received before transferring it to destination node), but MUST
omit it if Headers-Not-Recognized header field's entity concerns only
to headers added to initial request by middle-box. If the
aforementioned header concerns added header fields partly, middle-box
MUST change the entity so that it concerns only initial request
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: 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.
skipping to change at page 5, line 48 skipping to change at page 5, line 46
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.
[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. 17 change blocks. 
66 lines changed or deleted 43 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