Re: Headers-Not-Recognized for HTTP

another option is to go back to the original issue.

If you have a client-server application layered over HTTP that needs to 
know that certain information provided by the client is acted upon by 
the server, why not use something like SOAP,  where this information is 
transported in the content, rather than the headers.

this then doesn't provide incentive for people to proliferate new HTTP 
headers which would probably be either stripped or ignored by the vast 
majority of deployed infrastructure.

Regards

Adrien


On 23/11/2010 11:12 a.m., Sylvain Hellegouarch wrote:
>
>
> On Mon, Nov 22, 2010 at 9:24 PM, Mykyta Yevstifeyev 
> <evnikita2@gmail.com <mailto:evnikita2@gmail.com>> 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
> http://www.defuze.org
> http://twitter.com/lawouach