W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Mykyta Yevstifeyev <evnikita2@gmail.com>
Date: Tue, 23 Nov 2010 17:03:45 +0200
Message-ID: <4CEBD7D1.6030701@gmail.com>
To: Sylvain Hellegouarch <sh@defuze.org>
CC: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
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
Received on Tuesday, 23 November 2010 15:04:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC