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

Mykyta Yevstifeyev <evnikita2@gmail.com> Wed, 15 December 2010 09:20 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VSDmZV3FDH30uAM7QTj+0eLL+HReX40hNJ1S0Ih9+VRBtEI9qf6LqMmc0HC5Obbe/R yngQAPumGOwRYene8us/eWfDoKxsO/4NHYnmMOdaRV4VMWGNj2MuFUG8r1v9AUdRlgiL IXBrxJWl2qS1rWnhIVu2PA4Um3oGCRFzhN/EY=
MIME-Version: 1.0
In-Reply-To: <9AEDD923-5AE2-48F7-8180-3E0E97463274@mnot.net>
References: <20101213132808.2379.30041.idtracker@localhost> <C3557348-94A0-40AD-AC05-C51BB1126EA4@mnot.net> <4D078A60.7070403@gmail.com> <9AEDD923-5AE2-48F7-8180-3E0E97463274@mnot.net>
Date: Wed, 15 Dec 2010 11:21:48 +0200
Message-ID: <AANLkTi=x9H2ZsbA=o9xbxyheyHJ4ux-XKoe44_FyVRk+@mail.gmail.com>
Subject: Re: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: The IETF <ietf@ietf.org>, httpbis Group <ietf-http-wg@w3.org>
Precedence: list

Mark,

Some notes on what you said:

2010/12/14, Mark Nottingham <mnot@mnot.net>:
>
> 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/
>
>
>
>

RE: Last Call: <draft-yevstifeyev-http-headers-no… L.Wood
Re: Last Call: <draft-yevstifeyev-http-headers-no… Mykyta Yevstifeyev
Re: Last Call: <draft-yevstifeyev-http-headers-no… Julian Reschke
LC comments on draft-yevstifeyev-http-headers-not… Mark Nottingham
Re: LC comments on draft-yevstifeyev-http-headers… Mykyta Yevstifeyev
Re: LC comments on draft-yevstifeyev-http-headers… Mark Nottingham
Re: LC comments on draft-yevstifeyev-http-headers… Mykyta Yevstifeyev
Re: Last Call: <draft-yevstifeyev-http-headers-no… SM
Re: Last Call: <draft-yevstifeyev-http-headers-no… Mykyta Yevstifeyev
Re: Last Call: <draft-yevstifeyev-http-headers-no… Mykyta Yevstifeyev
Re: Last Call: <draft-yevstifeyev-http-headers-no… Julian Reschke
Re: Last Call: <draft-yevstifeyev-http-headers-no… Mykyta Yevstifeyev
Re: Last Call: <draft-yevstifeyev-http-headers-no… Julian Reschke
Re: Last Call: <draft-yevstifeyev-http-headers-no… Daniel Stenberg
Re: Last Call: <draft-yevstifeyev-http-headers-no… Daniel Stenberg
Re: Last Call: <draft-yevstifeyev-http-headers-no… Cullen Jennings
Re: Last Call: <draft-yevstifeyev-http-headers-no… SM
Re: Last Call: <draft-yevstifeyev-http-headers-no… Alexey Melnikov