Mark,
Some notes on what you said:
2010/12/14, Mark Nottingham <mnot(_at_)mnot(_dot_)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/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf