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

Re: Please Review my Internet-Draft

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 22 Nov 2010 13:01:02 -0700
Message-ID: <AANLkTimD_z94xUE3JQR9-4Hmz4sJfLERKKNAA_sOJZgB@mail.gmail.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Cc: ietf-http-wg@w3.org
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 <evnikita2@gmail.com>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
>>>
>>>
>>
>
>
Received on Monday, 22 November 2010 20:01:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT