- From: Sylvain Hellegouarch <sh@defuze.org>
- Date: Tue, 23 Nov 2010 15:59:26 +0100
- To: Mykyta Yevstifeyev <evnikita2@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
Received on Tuesday, 23 November 2010 15:00:04 UTC
> > 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. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach
Received on Tuesday, 23 November 2010 15:00:04 UTC