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

[Mark Nottingham <[e-mail]>]

On 15/12/2010, at 2:16 AM, Mykyta Yevstifeyev wrote:

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

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,

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