Hello all,
Let me explain some issues which were mentioned by Mark.
14.12.2010 2:09, Mark Nottingham wrote:
The use cases for this draft are highly speculative and unproven, even for something aspiring to be Experimental. I haven't seen any implementers express interest in it.
The draft does not cover what it means for a server to "recognise" a header, yet it places a MUST level requirement on this; e.g., if a server doesn't actively use the "Via" header, should it list it as not recognised? What about X-Forwarded-For? Deploying this on a server as-is means that a lot of extra bytes will be sent in responses (and not just because the field-name is so long, although that doesn't help). If the client sends a 'Range' header but the server chooses not to sent a partial response, should it be listed? And so on...
Firstly, why do we speak about extra bytes to be transferred now, almost
in 2011? Does it seem to be a great problem? And do you really think
that there will be *a lot* of such bytes? Secondly, 'doesn't actively
use' does not mean 'not supports'. The examples you list are not
appropriate for the situation we are discussing. I mean that if the
server completely does not support one of headers the client sent, it'll
form the corresponding response. And when the client receives, it will
avoid sending the corresponding header(s) - so, using this header will
allow to save 'extra bytes', as you say, than spend them. The proposal
has the opposite effect than you describe.
It's also under-specified; e.g, I haven't seen any analysis on the interaction of this mechanism with hop-by-hop headers, nor with content negotiation, nor with caching.
The points you raised are important, so I'll try to add some description
in the next versions.
Furthermore, the draft enables implementation of an anti-pattern for HTTP, by offering an alternative to the 'must ignore' pattern. I understand that the intent of the header is to enable debugging, but if it gains deployment, it will be very tempting for developers to build on top of it.
Therefore, I recommend that this draft NOT be published as an RFC (of any kind).
Regards,
I think the following issue seems to be discussed by this document too -
if not only the server, but the client does not recognize on of the
header in received packet. I wonder this problem wasn't raised so I'll
try to make the corresponding changes in the draft ASAP.
I'll let you know when the new version of the draft will be available.
All the best,
Mykyta Yevstifeyev
Begin forwarded message:
From: The IESG<iesg-secretary@xxxxxxxx>
Date: 14 December 2010 12:28:08 AM AEDT
To: IETF-Announce<ietf-announce@xxxxxxxx>
Subject: Last Call:<draft-yevstifeyev-http-headers-not-recognized-08.txt> ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
The IESG has received a request from an individual submitter to consider
the following document:
- ''Headers-Not-Recognized' HTTP Header Field'
<draft-yevstifeyev-http-headers-not-recognized-08.txt> as an
Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2011-01-14. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf