Subject: Please Review my Internet-Draft

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Nov 2010 09:33:53 +0200

Hello all,

I have recently made an I-D, which, I think,
would be interesting for the WG. You can
find it here:

http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/

Could you please review it?

Thank you for your time.
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Nov 2010 11:55:50 +0100

On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
> ...

Hi Mykyta,

a few thoughts:

- This would be interesting for debugging purposes. Not sure about 
things beyond that. For instance, what's the rational for the 
conformance requirements you make? IMHO, a server MUST continue to 
process the requests (because that's how 1xx status codes work), but the 
actual 103 message should only be a hint to the sender.

- The ABNF for the header should be a list of comma-separated headers 
(same syntax as for Vary, for instance)

- You'd need IANA considerations for the new header as well.

- In many cases, this will be extremely hard to implement, because the 
actual handling of a request requires several layers, and it would 
tricky to find out which headers were processed by whom. Also, in many 
cases, the final recipient might not be *able* to send a 1xx response 
(such as a Java servlet).

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Nov 2010 16:15:54 +0200

Julian, all,

I have read all these notes. Here are the answers:

22.11.2010 12:55, Julian Reschke wrote:
> process the requests (because that's how 1xx status codes work), but 
> the actual 103 message should only be a hint to the sender.
Yes, I have mentioned that the server MUST continue processing of the 
request.

    If a server sends a response with aforementioned status,
    it SHOULD continue  processing of client's request.

> - You'd need IANA considerations for the new header as well.
The information about not-processed headers will be put into the body
of the response.
> (such as a Java servlet).
Look here:

    If a server receives request with unknown (for it) headers, it*SHOULD*
    send a response with 'Some Headers Not Recognized' status.

If a server is not able to send the 103 code, it won't do, as
we don't set '*MUST*' comformancecriterion here.

> Best regards, Julian
I hope I've answered all the questions.
All the best,
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Nov 2010 16:24:09 +0100

>      it SHOULD continue  processing of client's request.

MUST != SHOULD.

> The information about not-processed headers will be put into the body

A 103 response doesn't have a body.

> we don't set '*MUST*' comformancecriterion here.

Understood. I was just trying to explain that for many servers, it will 
be hard to implement this.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Nov 2010 19:33:35 +0200

Julian,

Everything you proposed would be taken into
consideration.

Mykyta Yevstifeyev

22.11.2010 17:24, Julian Reschke wrote:
> Understood. I was just trying to explain that for many servers, it 
> will be hard to implement this.
>
> Best regards, Julian
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Nov 2010 21:49:47 +0200

Hello all,

A new version (-01) of discussed I-D is available
now. Here is a link to it.

https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/

All notes, listed below, were taken into
considerations.

Waiting for proposals for future improvements.
Mykyta Yevstifeyev

---

From: Robert Sanderson <[email-masked]>
Date: Mon, 22 Nov 2010 13:01:02 -0700

Dear Mykyta,

I don't understand the motivation for introducing a new status as well as
the proposed response header.

As you note in your Motivation section:
  Generally, if a server does not recognize the header, it simply ignores
it.

In my opinion this is the web working as intended, and to change it would
break a huge amount of infrastructure.

On the other hand, the response header is informative and may assist a
client in future requests, or in understanding why the response was not the
one expected.  My suggestion would be to remove the status code, and just
register the response header.

Hope that helps,

Rob Sanderson
Los Alamos National Laboratory

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Nov 2010 22:24:12 +0200

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:

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

22.11.2010 22:01, Robert Sanderson wrote:
>
> Dear Mykyta,
>
> I don't understand the motivation for introducing a new status as well 
> as the proposed response header.
>
>   Generally, if a server does not recognize the header, it simply 
> ignores it.
>
> In my opinion this is the web working as intended, and to change it 
> would break a huge amount of infrastructure.
>
> client in future requests, or in understanding why the response was 
> not the one expected.  My suggestion would be to remove the status 
> code, and just register the response header.
>
> Hope that helps,
>
> Rob Sanderson
> On Mon, Nov 22, 2010 at 12:49 PM, Mykyta Yevstifeyev 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello all,
>
>             Understood. I was just trying to explain that for many
>             servers, it will be hard to implement this.
>
>             Best regards, Julian
>
>
>
>
>

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 22 Nov 2010 23:12:09 +0100

> critical won't be proposed, I'll initiate the process

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

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 23 Nov 2010 12:27:30 +1300

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 
> 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

---

From: mike amundsen <[email-masked]>
Date: Mon, 22 Nov 2010 19:08:33 -0500

Mykyta:

I think the functionality described in this I-D is covered by the
Warning header [1] w/ the code of 199 or 299 (along with your text).

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

#RESTFest 2010
http://rest-fest.googlecode.com

On Mon, Nov 22, 2010 at 18:27, Adrien de Croy <[email-masked]> wrote:
> 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.
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Nov 2010 11:10:38 +0100

> majority of deployed infrastructure.

RFC 2774 comes to mind.

Best regards, Julian