Subject: draft-yevstifeyev-http-headers-not-recognized-01.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 23 Nov 2010 11:16:45 +0200

Hello all,

Here are some notes on discussed issues:

2010/11/22, Bill Atwood <[email-masked]>:
> In the Abstract, the phrase "not proceed" should be "not processed".
>
> In addition, since "not" is a curious object that can often be
> mis-interpreted or can often be interpreted ambiguously, especially in
> cases similar to the ones that you are discussing, I would encourage you
> to substitute "unrecognized" for "not recognized" and "unprocessed" for
> "not processed" throughout your document.
>
>   Bill Atwood

Will be taken into acount while prparing new version
of the I-D.

2010/11/23, Sylvain Hellegouarch <[email-masked]>:
> On Mon, Nov 22, 2010 at 9:24 PM, Mykyta Yevstifeyev
> <[email-masked]>wrote:
>
>>  Hello all,
>>
>> The idea proposed by Robert seems very interesting to me.
>> I have remade my I-D according to the proposals.
>> You are able to find it here:
>>
>>
>> https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
>>
>> I think everything is clear in this document and
>> it needs only editorial changes. IMO if nothing
>> critical won't be proposed, I'll initiate the process
>> of RFC publication.
>>
>> All the best,
>> Mykyta Yevstifeyev
>>
>
> It looks a bit like a ping/pong game, with your proposal, instead of having
> a server ignoring headers, we'll have clients mostly not knowing what to do
> with that new response. Besides, RFC2616 says explicitely that unknown
> headers should be ignored by servers.
>
> If your application is strict and conservative about what it accepts, you
> could still use one of the 4xx error codes. They are plenty of them.
>
> --
> - Sylvain

If a server sends 4xx code, it stops procesing the request.
Generally unrecognized headers are not critical - all
'vital' headers MUST be supported by servers. If a client receives
such a response, it SHOULD avoid sending requests
with mentioned headers while server MUST cntinue processing
the request.

2010/11/23, mike amundsen <[email-masked]>:
> Mykyta:
>
> I think the functionality described in this I-D is covered by the
> Warning header [1] w/ the code of 199 or 299 (along with your text).
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>

Warning headers wth 199 or 299 codes are 'understandable'
for people and not for user agents, as it carries arbitrary
information without any specified syntax.

I hope I have answered all your questions.

All the best,
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Nov 2010 11:13:30 +0100

On 23.11.2010 10:16, Mykyta Yevstifeyev wrote:
> ...
> ...

*Why* "SHOULD" it avoid sending those? What's the problem you're trying 
to solve? Wasted bits? It would be helpful to understan

>...

Best regards, Julian

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 23 Nov 2010 11:37:33 +0100

On Tue, Nov 23, 2010 at 11:13 AM, Julian Reschke <[email-masked]>wrote:

> *Why* "SHOULD" it avoid sending those? What's the problem you're trying to
> solve? Wasted bits? It would be helpful to understan
>
>
Also I'm afraid we'd end up with a ping/pong game where clients would likely
dismiss the new status code anyway as servers ignore currently headers they
don't understand.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 23 Nov 2010 16:53:16 +0200

23.11.2010 12:37, Sylvain Hellegouarch wrote:
> On Tue, Nov 23, 2010 at 11:13 AM, Julian Reschke 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     *Why* "SHOULD" it avoid sending those? What's the problem you're
>     trying to solve? Wasted bits? It would be helpful to understan
>
>
> Also I'm afraid we'd end up with a ping/pong game where clients would 
> likely dismiss the new status code anyway as servers ignore currently 
> headers they don't understand.
IMO it wouldn't be a great trouble for servers to add another one HEADER 
(not separate
status code!) with a list of headers it hasn't recognized. The aim of 
this header is to
inform the client about not processed headers. However there is no MUST 
criterion
for avoiding sending the 'not-recognizable' headers. If the client wants 
them to be sent,
it will sent, but it is only RECOMMENDED that these headers are not sent 
(siad in other
words).
Moreover, if a sever sends the corresponding headers, a client MAY try 
to change it
to acceptable one (for server) in case it is critical for it (client).
Finally, server SHOULD (and not MUST) send the 'Headers-Not-Recognized' 
Header.
If it is a big difficulty for them (but it's hard to imagine), they 
won't do this.
I don't understand what all this fuss is for?

Mykyta Yevstifeyev

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 23 Nov 2010 15:59:26 +0100

>
> uldn't be a great trouble for servers to add another one HEADER (not
> separate
> status code!) with a list of headers it hasn't recognized. The aim of this
> header is to
> Moreover, if a sever sends the corresponding headers, a client MAY try to
> change it
> If it is a big difficulty for them (but it's hard to imagine), they won't
> do this.
No fuss at all, just discussion ;)
The problem is not much about the level of compliance you're setting in your
proposal but the rationale behind it. As Julian said, for debugging purpose
I guess this could be useful but in production, I'm not certain clients will
change their headers just because a server  can't deal with them, more so if
the request goes through anyway.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 23 Nov 2010 17:03:45 +0200

23.11.2010 16:59, Sylvain Hellegouarch wrote:
>
>     uldn't be a great trouble for servers to add another one HEADER
>     (not separate
>     status code!) with a list of headers it hasn't recognized. The aim
>     of this header is to
>     inform the client about not processed headers. However there is no
>     MUST criterion
>     for avoiding sending the 'not-recognizable' headers. If the client
>     wants them to be sent,
>     it will sent, but it is only RECOMMENDED that these headers are
>     not sent (siad in other
>     words).
>     Moreover, if a sever sends the corresponding headers, a client MAY
>     try to change it
>     Finally, server SHOULD (and not MUST) send the
>     'Headers-Not-Recognized' Header.
>     If it is a big difficulty for them (but it's hard to imagine),
>     they won't do this.
> The problem is not much about the level of compliance you're setting 
> in your proposal but the rationale behind it. As Julian said, for 
> debugging purpose I guess this could be useful but in production, I'm 
> not certain clients will change their headers just because a server 
>  can't deal with them, more so if the request goes through anyway.
But aren't debugging purposes a weighty argument? The start of
end-user service is debugging and testing - so it as important as
routine use?
Mykyta Yevstifeyev

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 23 Nov 2010 17:17:19 +0100

> end-user service is debugging and testing - so it as important as
It is an interesting feature for sure, what I'm saying is that it might not
well be respected. I think it would be if one could measure how strong of an
impact unused or incorrect headers are on an infrastructure. If this is a
really critical issue, then your proposal makes even more sense.