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@xxxxxxxxx for
further information.
All the best,
Mykyta Yevstifeyev
|
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf