Subject: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 14 Dec 2010 11:09:48 +1100

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...

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. 

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,

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: 14 December 2010 12:28:08 AM AEDT
> To: IETF-Announce <[email-masked]>
> 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
> [email-masked] mailing lists by 2011-01-14. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham   http://www.mnot.net/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 14 Dec 2010 15:17:16 +0000

Hello all,

Let me explain some issues which were mentioned by Mark.

> 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…
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.
> Therefore, I recommend that this draft NOT be published as an RFC (of any kind).
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<[email-masked]>
>> To: IETF-Announce<[email-masked]>
>> Subject: Last Call:<draft-yevstifeyev-http-headers-not-recognized-08.txt>  ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
>>
>>
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Dec 2010 08:29:10 +1100

> Firstly, why do we speak about extra bytes to be transferred now, almost in 2011? Does it seem to be a great problem?

I can point you at lots of people who work at Amazon, Yahoo, Google, Akamai and other large-scale Web development shops who are painfully aware of both the costs of bandwidth (especially in many non-US markets) and the effect of adding packets on end-user perceived latency. It matters very much.

> 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.

As it sits, it's impossible to say; your draft doesn't contain the word "supports" "actively use" or anything else to describe how this mechanism would work in practice, nor are there examples.

> 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.

To achieve that effect, you have to get widespread support in both servers and clients. Have you had any discussions with vendors of either?

What are your goals here, overall? From previous discussions, I'd thought it was to provide a debugging mechanism. Here, you express interest in saving bytes. I suspect that having both as goals will be pulling you in different directions...

Regards,

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 15 Dec 2010 11:21:48 +0200

Mark,

Some notes on what you said:

2010/12/14, Mark Nottingham <[email-masked]>:
>>> 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...
>
>> in 2011? Does it seem to be a great problem?
>
> I can point you at lots of people who work at Amazon, Yahoo, Google, Akamai
> and other large-scale Web development shops who are painfully aware of both
> the costs of bandwidth (especially in many non-US markets) and the effect of
> adding packets on end-user perceived latency. It matters very much.
>
>
>> 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.
>
> As it sits, it's impossible to say; your draft doesn't contain the word
> "supports" "actively use" or anything else to describe how this mechanism
> would work in practice, nor are there examples.
>
Yes, you are right, my draft does not contain these issues. But for
this *draft* and *last call* stand for - comments and improvements. So
I'll correct it.
>
>> 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.
>
> To achieve that effect, you have to get widespread support in both servers
> and clients. Have you had any discussions with vendors of either?
>
At the moment I didn't.
> What are your goals here, overall? From previous discussions, I'd thought it
> was to provide a debugging mechanism. Here, you express interest in saving
> bytes. I suspect that having both as goals will be pulling you in different
> directions...
The main goal is debugging - I was only trying to persuade you that
that would not make 'extra bytes' sent but would have the opposite
meaning.

All the best,
Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Dec 2010 15:53:49 +0200

Hello all,

Some answers that concern issues discussed below.

17.12.2010 13:15, SM wrote:
> At 05:28 13-12-10, The IESG wrote:
> These comments are not meant to discourage the author from bringing 
> proposals to the IETF.
>
> Version -01 of this draft was submitted on November 21.  It's not even 
> a month and the draft is already at version -09.  I don' think that 
> "commit early, commit often" applies to Internet-Drafts.  As this is 
> probably the author's first draft going for Last Call, it would have 
> been helpful to assign a document shepherd for the document to help 
> the author with the IETF standards process.
You are right, that is my first document in Last Call.
>
> As a nit, the intended status should be "Experimental".
I'll correct it.
>
> From the Abstract (draft-yevstifeyev-http-headers-not-recognized-09):
>
>   "This document defines mechanism which allows HTTP servers to notify
>    clients about not recognized or not proceed headers"
>
> Shouldn't that have been "processed" instead of "proceed"?
I find 'processed' more acceptable for this case. However to mind it 
would be better to mention 'not supported'
>
> In Section 1.1:
>
>  "However, all hosts are not able to support all the HTTP headers."
>
> Shouldn't that be HTTP servers?
No. It should be 'hosts' in abstract - that is a mistake.
>
> From Section 2.1:
>
>   "If the HTTP host receives HTTP packet which contains some headers
>    which are not supported by it, it is RECOMMENDED for it to include
>    the Headers-Not-Recognized header in the response."
>
> That could be rewritten as:
>
>   If the HTTP server receives a request header field that it does not 
> support
That will be corrected.
>
>   "Intermediate systems (also called middle-boxes), such as proxies,
>    tunnels, gateways etc. MUST transfer the packets with Headers-Not-
>    Recognized field to the destination host without changing the entity
>    of this header if the unrecognized header had been present in the
>    initial HTTP request (i. e. request which intermediate system
>    received before transferring it to destination node), but SHOULD omit
>    it if Headers-Not-Recognized header entity concerns to header added
>    to initial request by middle-box."
>
> What do packets have to do with HTTP headers?
What do you mean? Packets have nothing to do with headers, there is 
nothing about this in paragraph above. Maybe you meant middle-boxes?
>
> In his replies during the Last Call [1][2], the author mentioned that 
> this header is useful for debugging.  I don't see any mention of that 
> in the proposal.
Maybe, I'll add something related to this topic.

I'll let you know as soon new version of the draft will be available 
(maybe that will be at the end of Last Call).

All the best,
Mykyta Yevstifeyev
> -sm
P.S. Could you please let me know what is your full name?
>
> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg64867.html
> 2. http://www.ietf.org/mail-archive/web/ietf/current/msg64838.html
>

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 17 Dec 2010 15:14:10 +0100 (CET)

> What do you mean? Packets have nothing to do with headers, there is nothing 
> about this in paragraph above. Maybe you meant middle-boxes?

Read through your -09 spec again. You speak of "HTTP packets" in several 
places, where they should rather be "HTTP request" or "HTTP responses" etc.

I also find the use of 'host' very confusing in the document as it is clearly 
used instead of the more proper 'client' or 'server' in some places.

The second paragraph in section 2.1 combines both these mistakes and make a 
blob of text that I cannot understand:

    When HTTP host receives HTTP packet with Headers-Not-Recognized
    header, it is RECOMMENDED that it avoids sending packets with headers
    with mentioned in it names or tries to change them so that it is able
    to recognize and process them.

Does this say that if a client learns about headers that the server doesn't 
support, it shouldn't send them in subsequent requests?

-- 

  / daniel.haxx.se

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Dec 2010 16:20:26 +0200

17.12.2010 16:14, Daniel Stenberg wrote:
> Read through your -09 spec again. You speak of "HTTP packets" in 
> several places, where they should rather be "HTTP request" or "HTTP 
> responses" etc.
Maybe I meant HTTP messages here.
>
> I also find the use of 'host' very confusing in the document as it is 
> clearly used instead of the more proper 'client' or 'server' in some 
> places.
In previous version there have been the 'server' and 'client' terms 
instead 'host'. However it is obvious for me that there can be as 
servers as clients that do not recognize some headers of another side of 
exchange.
>
> The second paragraph in section 2.1 combines both these mistakes and 
> make a blob of text that I cannot understand:
>
> Does this say that if a client learns about headers that the server 
> doesn't support, it shouldn't send them in subsequent requests?
No, that just describes the behavior of the host after receiving the 
H-N-R header. However this paragraph needs improvement, and I'll do that 
in the next version of the draft, which will bw available at the end of 
Last Call.

All the best,
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Dec 2010 15:29:14 +0100

On 17.12.2010 15:20, Mykyta Yevstifeyev wrote:
> ...
> ...

But clients can't respond with the header, so there's no point in 
pretending this applies to them.

> ...

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Dec 2010 16:33:19 +0200

> pretending this applies to them.
In my document the term 'header' means 'header field' since client are 
able to put any header to the request and I meant just it.

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Dec 2010 16:00:29 +0100

> able to put any header to the request and I meant just it.

I realize that you use "header" as synonym for "header field".

What I was trying to say was that it doesn't make sense to speak of 
clients and servers in general, when it's really only the server who can 
set the H-N-R header field.

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 17 Dec 2010 16:03:49 +0100 (CET)

On Fri, 17 Dec 2010, Mykyta Yevstifeyev wrote:

> However this paragraph needs improvement, and I'll do that in the next 
> version of the draft, which will bw available at the end of Last Call.

It might be a good idea to just post your updated versions of the paragraphs 
discussed here so that we can iterate over them faster and without you having 
to issue new drafts all the time...

-- 

  / daniel.haxx.se

---

From: Tony Hansen <[email-masked]>
Date: Fri, 17 Dec 2010 10:29:32 -0500

> able to put any header to the request and I meant just it.

You might consider changing to using the term header field, since that's 
the more socially acceptable term.

     Tony Hansen

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Dec 2010 16:45:49 -0700

I'm pretty surprised to see this in IETF LC - its not at the level where it is ready to have a WG start working on the idea. 

It's unclear what this draft is for, who wants it, or how it would work. Consider a HTTP request going to something like GAE. First some front end web gets the message, call this server A, it probably forwards on to separate web server running the python system, call this B, this pass on to a framework like say django, call this C, which passes on to end application call this D. It's really unclear what software is responsible for knowing which header each of A, B, C, and D supports or how the proposed header would get filled out in the response.  It gets even more unclear as you start adding in caches, TLS accelerators, and such. It's not clear to me what the client would be able to do even if it had this information. 

I don't think this should be published until it has actually been discussed in the appropriate WG.