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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mark,

Some notes on what you said:

2010/12/14, Mark Nottingham <mnot@xxxxxxxx>:
>
> 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.
>
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
>
> Regards,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]