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

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
>     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?
>
>
> 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.
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?
>
> -- 
> - Sylvain
> http://www.defuze.org
> http://twitter.com/lawouach
Mykyta Yevstifeyev