Hello all,
This message summarizes the first Last Call week on
draft-yevstifeyev-http-headers-not-recognized. The document have been
discussed on IETF Discussion and HTTPBIS WG mailing lists.
I include the most current entity to be discussed:
1. Introduction
1.1. Motivation
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
add any header field to the HTTP message. However, all hosts are not
able to support all the header fields. Generally, if a it host does
not support the header field, it is simply ignored. The another side
of exchange is not notified about not processed header fields.
This document proposes mechanism which allows HTTP hosts to notify
another hosts about not recognized headers.
The proposal is to send a response with definite header field to the
host if one or more header fields of request are not supported. This
document defines Headers-Not-Recognized HTTP header field to be used
in such occasion.
2. Technical Overview
2.1 Model of Work
If the HTTP host receives HTTP message which contains some header
fields which are not supported by it, it is RECOMMENDED for it to
include the Headers-Not-Recognized header field in the response to
the host that sent not supported header fields. Information about not
supported header field is to be put in this header field following
the rules of Section 2.2 of this document. The Headers-Not-Recognized
header field MUST 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, not intended to be used or 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 packets with
header fields with mentioned in it names to source (for message with
this header) 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,
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
'Headers-Not-Recognized' header field has the following format:
headers_not_recognized = 1#header_name
header_name = 1*VCHAR
This is the fragment of the text which is planned to be posted as a
draft nearly after 1 January (the half of Last Call period) if no
*critical* comments will be received.
This text reflects almost all the comments I received during the Last
Call and found appropriate. However any other suggestion are still welcome.
You may feel free to contact me at evnikita2(_at_)gmail(_dot_)com for further
information.
All the best,
Mykyta Yevstifeyev
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf