p2: Considerations for new headers

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

p2: Considerations for new headers

Mark Nottingham-2
We should consider adding the following to the laundry list of considerations in p2 8.3.1:

* Whether the field should be stored by origin servers that understand it upon a PUT request.

Furthermore, I think we should change:

* How the header field might interact with caching (see [Part6]).

to:

* When the header is used in requests and affects response selection [ref], it is good practice to advise listing that header in the Vary response header [ref].

Finally, we should add (near the top of the section):

"""
New header fields cannot change the semantics of a message in an incompatible fashion. That is, it is not possible to require recipients to understand a header field through its mere presence. However, new methods and status codes can require the presence of headers in their definitions, in the scope of the message they occur within.
"""

Make sense?


--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: p2: Considerations for new headers

Julian Reschke
On 2013-04-24 10:03, Mark Nottingham wrote:

> We should consider adding the following to the laundry list of considerations in p2 8.3.1:
>
> * Whether the field should be stored by origin servers that understand it upon a PUT request.
>
> Furthermore, I think we should change:
>
> * How the header field might interact with caching (see [Part6]).
>
> to:
>
> * When the header is used in requests and affects response selection [ref], it is good practice to advise listing that header in the Vary response header [ref].
>
> Finally, we should add (near the top of the section):
>
> """
> New header fields cannot change the semantics of a message in an incompatible fashion. That is, it is not possible to require recipients to understand a header field through its mere presence. However, new methods and status codes can require the presence of headers in their definitions, in the scope of the message they occur within.
> """
>
> Make sense?

Sounds good to me.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: p2: Considerations for new headers

Alexey Melnikov
Looks good to me as well.

On 24 Apr 2013, at 09:06, Julian Reschke <[hidden email]> wrote:

> On 2013-04-24 10:03, Mark Nottingham wrote:
>> We should consider adding the following to the laundry list of considerations in p2 8.3.1:
>>
>> * Whether the field should be stored by origin servers that understand it upon a PUT request.
>>
>> Furthermore, I think we should change:
>>
>> * How the header field might interact with caching (see [Part6]).
>>
>> to:
>>
>> * When the header is used in requests and affects response selection [ref], it is good practice to advise listing that header in the Vary response header [ref].
>>
>> Finally, we should add (near the top of the section):
>>
>> """
>> New header fields cannot change the semantics of a message in an incompatible fashion. That is, it is not possible to require recipients to understand a header field through its mere presence. However, new methods and status codes can require the presence of headers in their definitions, in the scope of the message they occur within.
>> """
>>
>> Make sense?
>
> Sounds good to me.
>
> Best regards, Julian
>
>

Reply | Threaded
Open this post in threaded view
|

Re: p2: Considerations for new headers

Julian Reschke
In reply to this post by Julian Reschke
On 2013-04-24 10:06, Julian Reschke wrote:
> On 2013-04-24 10:03, Mark Nottingham wrote:
>> We should consider adding the following to the laundry list of
>> considerations in p2 8.3.1:
>>
>> * Whether the field should be stored by origin servers that understand
>> it upon a PUT request.

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2227>

>> Furthermore, I think we should change:
>>
>> * How the header field might interact with caching (see [Part6]).
>>
>> to:
>>
>> * When the header is used in requests and affects response selection
>> [ref], it is good practice to advise listing that header in the Vary
>> response header [ref].

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2227> (slightly
rephrased).

>> Finally, we should add (near the top of the section):
>>
>> """
>> New header fields cannot change the semantics of a message in an
>> incompatible fashion. That is, it is not possible to require
>> recipients to understand a header field through its mere presence.
>> However, new methods and status codes can require the presence of
>> headers in their definitions, in the scope of the message they occur
>> within.
>> """
>>
>> Make sense?
> ...

I think the consequences of the first sentence are not totally clear.

- you can set a new header field on a message, but you can not rely on
the recipient looking at it (because it's "must ignore")

- you could require the presence of a new header field on a request
using a new method, or on a response using a new status code

...but then, you could require it in other cases as well (think a new
auth scheme, a successful upgrade, an applied Preference...).

Not sure how to explain this better...

Best regards, Julian



Reply | Threaded
Open this post in threaded view
|

Re: p2: Considerations for new headers

James M Snell
FWIW, I'm comfortable with Mark's suggested text. I think it gets the
point across ok, although it's not entirely clear what "understand a
header field" means. Perhaps it would be better to say that the mere
presence of a new header field cannot compel implementations to take
any specific action. Either way, tho, I can live with Mark's wording.

On Thu, Apr 25, 2013 at 7:41 AM, Julian Reschke <[hidden email]> wrote:
[snip]

>>> Finally, we should add (near the top of the section):
>>>
>>> """
>>> New header fields cannot change the semantics of a message in an
>>> incompatible fashion. That is, it is not possible to require
>>> recipients to understand a header field through its mere presence.
>>> However, new methods and status codes can require the presence of
>>> headers in their definitions, in the scope of the message they occur
>>> within.
>>> """
>>>
>>> Make sense?
>>
>> ...
>
>
> I think the consequences of the first sentence are not totally clear.
>
> - you can set a new header field on a message, but you can not rely on the
> recipient looking at it (because it's "must ignore")
>
> - you could require the presence of a new header field on a request using a
> new method, or on a response using a new status code
>
> ...but then, you could require it in other cases as well (think a new auth
> scheme, a successful upgrade, an applied Preference...).
>
> Not sure how to explain this better...
>
> Best regards, Julian
>
>
>