Please Review my Internet-Draft

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Please Review my Internet-Draft

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

Reply | Threaded
Open this post in threaded view
|

Re: Please Review my Internet-Draft

Julian Reschke
On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Please Review my Internet-Draft

Mykyta Yevstifeyev
Julian, all,

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

22.11.2010 12:55, Julian Reschke wrote:
On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
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?

...

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.

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

The information about not-processed headers will be put into the body
of the response.

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

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' comformance criterion here.

Best regards, Julian


I hope I've answered all the questions.
All the best,
Mykyta Yevstifeyev


Reply | Threaded
Open this post in threaded view
|

Re: Please Review my Internet-Draft

Julian Reschke
On 22.11.2010 15:15, Mykyta Yevstifeyev wrote:

> Julian, all,
>
> I have read all these notes. Here are the answers:
>
> 22.11.2010 12:55, Julian Reschke wrote:
>> On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
>>> 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?
>>> ...
>>
>> 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.
> 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.

MUST != SHOULD.

>> - 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.
> The information about not-processed headers will be put into the body
> of the response.

A 103 response doesn't have a body.

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

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

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Please Review my Internet-Draft

Mykyta Yevstifeyev
Julian,

Everything you proposed would be taken into
consideration.

Mykyta Yevstifeyev

22.11.2010 17:24, Julian Reschke wrote:

> On 22.11.2010 15:15, Mykyta Yevstifeyev wrote:
>> Julian, all,
>>
>> I have read all these notes. Here are the answers:
>>
>> 22.11.2010 12:55, Julian Reschke wrote:
>>> On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
>>>> 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?
>>>> ...
>>>
>>> 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.
>> 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.
>
> MUST != SHOULD.
>
>>> - 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.
>> The information about not-processed headers will be put into the body
>> of the response.
>
> A 103 response doesn't have a body.
>
>>> - 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).
>> 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.
>
> Understood. I was just trying to explain that for many servers, it
> will be hard to implement this.
>
> Best regards, Julian
>


Reply | Threaded
Open this post in threaded view
|

Re: Please Review my Internet-Draft

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


22.11.2010 19:33, Mykyta Yevstifeyev wrote:

> Julian,
>
> Everything you proposed would be taken into
> consideration.
>
> Mykyta Yevstifeyev
>
> 22.11.2010 17:24, Julian Reschke wrote:
>> On 22.11.2010 15:15, Mykyta Yevstifeyev wrote:
>>> Julian, all,
>>>
>>> I have read all these notes. Here are the answers:
>>>
>>> 22.11.2010 12:55, Julian Reschke wrote:
>>>> On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
>>>>> 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?
>>>>> ...
>>>>
>>>> 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.
>>> 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.
>>
>> MUST != SHOULD.
>>
>>>> - 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.
>>> The information about not-processed headers will be put into the body
>>> of the response.
>>
>> A 103 response doesn't have a body.
>>
>>>> - 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).
>>> 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.
>>
>> Understood. I was just trying to explain that for many servers, it
>> will be hard to implement this.
>>
>> Best regards, Julian
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Please Review my Internet-Draft

Robert Sanderson

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



On Mon, Nov 22, 2010 at 12:49 PM, Mykyta Yevstifeyev <[hidden email]> wrote:
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


22.11.2010 19:33, Mykyta Yevstifeyev wrote:
Julian,

Everything you proposed would be taken into
consideration.

Mykyta Yevstifeyev

22.11.2010 17:24, Julian Reschke wrote:
On 22.11.2010 15:15, Mykyta Yevstifeyev wrote:
Julian, all,

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

22.11.2010 12:55, Julian Reschke wrote:
On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
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?
...

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

MUST != SHOULD.

- 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.
The information about not-processed headers will be put into the body
of the response.

A 103 response doesn't have a body.

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

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

Best regards, Julian





Reply | Threaded
Open this post in threaded view
|

Headers-Not-Recognized for HTTP (was: Please review my Internet-Draft)

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

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.

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



On Mon, Nov 22, 2010 at 12:49 PM, Mykyta Yevstifeyev <[hidden email]> wrote:
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


22.11.2010 19:33, Mykyta Yevstifeyev wrote:

Julian,

Everything you proposed would be taken into

consideration.

Mykyta Yevstifeyev


22.11.2010 17:24, Julian Reschke wrote:

On 22.11.2010 15:15, Mykyta Yevstifeyev wrote:
Julian, all,

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


22.11.2010 12:55, Julian Reschke wrote:

On 22.11.2010 08:33, Mykyta Yevstifeyev wrote:
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?

...

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

MUST != SHOULD.

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

The information about not-processed headers will be put into the body
of the response.

A 103 response doesn't have a body.

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

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

Best regards, Julian







Reply | Threaded
Open this post in threaded view
|

Re: Headers-Not-Recognized for HTTP (was: Please review my Internet-Draft)

Sylvain Hellegouarch


On Mon, Nov 22, 2010 at 9:24 PM, Mykyta Yevstifeyev <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Headers-Not-Recognized for HTTP

Adrien de Croy

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Headers-Not-Recognized for HTTP

mamund
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 <[hidden email]> wrote:

>
> 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 <[hidden email]>
> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Headers-Not-Recognized for HTTP

Julian Reschke
In reply to this post by Adrien de Croy
On 23.11.2010 00:27, Adrien de Croy wrote:

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

RFC 2774 comes to mind.

Best regards, Julian