Re: Informal Last Call for HTTP Preference Header

+1... good catch Martin. In general, the preferences as stated have
been intentionally designed to minimize potential security issues but
the resource allocation issue is definitely a potential risk. If you
don't mind, I'll likely adopt the text you suggest nearly verbatim.

On Tue, Jan 31, 2012 at 2:42 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> I have only one real problem with the document as it stands.
>
> Though the document requires that new preferences describe security
> considerations, security considerations for the preferences included
> are non-existent.  At a minimum, something needs to be said about the
> security properties of the included preferences.
>
> I suspect that the story is, in general:
>
> A server could incur greater costs in attempting to comply with a
> particular preference (for instance, the cost of providing a
> representation in a response that would not ordinarily contain one; or
> the commitment of resources necessary to track state for an
> asynchronous response).  Unconditional compliance from a server could
> allow the use of preferences for denial of service.  A server can
> ignore an expressed preference to avoid expending resources that it
> does not wish to commit.
>
> --Martin
>
> On 31 January 2012 13:28, James Snell <jasnell@gmail.com> wrote:
>> I just posted an update for the HTTP Prefer Header altering the
>> intended status from "Informational" to "Standards Track". No
>> additional changes were made. As I have not received any further
>> technical input on the specification, I am issuing an *Informal* Last
>> Call for comments before I request that it be kicked up the chain for
>> review.
>>
>> Mark Nottingham has agreed to serve as the document shepherd for
>> helping to move it forward.
>>
>> Current Draft: http://www.ietf.org/id/draft-snell-http-prefer-11.txt
>>
>> - James
>>

Received on Tuesday, 31 January 2012 23:35:52 UTC