Subject: Informal Last Call for HTTP Preference Header

From: James Snell <[email-masked]>
Date: Tue, 31 Jan 2012 13:28:17 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2012 14:42:41 -0800

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

---

From: James Snell <[email-masked]>
Date: Tue, 31 Jan 2012 15:35:19 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2012 15:50:00 -0800

On 31 January 2012 15:35, James Snell <[email-masked]> wrote:
> If you

That was the intent behind including it.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 31 Jan 2012 15:58:11 -0800

Hi James,

> Current Draft: http://www.ietf.org/id/draft-snell-http-prefer-11.txt

Can you clarify the meaning of an ETag header returned in the response to a 
PUT with a Prefer:return-representation header. Would that ETag refer to 
the resource whose representation is being returned? If so, could we please 
include ETag in the example. If not, then we really need a way to get the 
actual ETag for the returned representation - otherwise 
Prefer:return-representation is not that useful.

-- 
Cyrus Daboo

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Feb 2012 14:39:29 +1300

On 01.02.2012 12:58, Cyrus Daboo wrote:
> Hi James,
>
> --On January 31, 2012 1:28:17 PM -0800 James Snell 
> <[email-masked]> wrote:
>
> Can you clarify the meaning of an ETag header returned in the
> response to a PUT with a Prefer:return-representation header. Would
> that ETag refer to the resource whose representation is being
> returned?

If it does not something is badly broken. HTTPbis part 4 section 2.3:
"
2.3. ETag

    The ETag header field provides the current entity-tag for the
    selected representation.
"

> If so, could we please include ETag in the example. If not,
> then we really need a way to get the actual ETag for the returned
> representation - otherwise Prefer:return-representation is not that
> useful.

+1.

AYJ