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

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

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

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