Subject: Re: Last Call: <draft-snell-http-prefer-14.txt> (Prefer Header for HTTP) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Oct 2012 17:12:58 +0200

Hi James,

see below for my (mostly editorial) feedback:

Multiple times: s/header/header field/

1.  Introduction

    Within the course of processing an HTTP request there are typically a
    range of required and optional behaviors that a server or
    intermediary can employ.  These often manifest is a variety of subtle
    and not-so-subtle ways within the response.

s/is/in/

    For example, when using the HTTP PUT method to modify a resource --
    similar to that defined for the Atom Publishing Protocol [RFC 5023]

reference to RFC 5023 is missing

    The rigid, must-understand semantics of the Expect header, therefore,

    make it a poor choice for the general expression of optional
    preferences that may be specific to an individual application and are
    therefore unknown to an intermediary or are otherwise irrelevant to
    the intermediaries successful handling of the request and response.

    Another option available to clients is to utilize Request URI query-
    string parameters to express preferences.  Doing so, however, results
    in a variety of issues affecting the cacheability of responses.

Comment: not according to the spec; but there are other issues with it, 
such as overloading the URI namespace.

    As an alternative, this specification defines a new HTTP request
    header field that can be used by clients to request that optional
    behaviors be applied by a server during the processing the request.
    Additionally, a handful of initial preference tokens for use with the
    new header are defined.

    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
    and "OPTIONAL" are to be interpreted as described in [RFC2119].

ID-Nits complained it couldn't find this note. It probably needs some 
adjustment.

1.1.  Syntax Notation

    This specification uses the Augmented Backus-Naur Form (ABNF)
    notation of [RFC5234] and includes, by reference, the "token",
    "word", "OWS", "BWS" rules and the #rule extension as defined within
    Sections 1.2 and 3.2.4 of [I-D.ietf-httpbis-p1-messaging].

Note: need to re-check the section numbers, they might have moved.

2.  The Prefer Request Header Field

    The Prefer request-header field is used to indicate that particular
    server behaviors are preferred by the client, but not required for
    successful completion of the request.  Prefer is similar in nature to
    the Expect header field defined by Section 9.3 of
    [I-D.ietf-httpbis-p2-semantics] with the exception that servers are

Ditto.

    If a particular preference token or parameter is specified multiple
    times, repeated occurrences MUST be ignored without signaling an
    error or otherwise altering the processing of the request.

That means: first wins, right? The repeated occurrences might have 
different parameters...

    The Prefer request header field is end-to-end and MUST be forwarded
    by a proxy if the request is forwarded.

That's something *this* spec can not require; it should follow from 
HTTPbis, right?

s/header/header field/

    No significance is given to the order in which preference tokens
    appear within a request.

Really? What if a token is repeated with different parameters?

2.1.  Content Negotiation and Cache Considerations

    Note that while the Prefer header field is not intended to be used as
    content negotiation mechanism, the application of a preference
    potentially could affect the caching characteristics of a response.
    Specifically, if a server supports the optional application of a
    preference that could even just potentially result in a variance to a
    cache's handling of a response entity, a Vary header field MUST be
    included with the response listing the Prefer header field regardless
    of whether the client actually used Prefer in the request.

    Because of the inherent complexities involved with properly
    implementing server-driven content negotiation, effective caching,
    and the application of optional preferences, implementors must

...avoid lowercase RFC2119 keywords...

    exercise caution when utilizing preferences in such a way as to
    impact the caching of a response and SHOULD NOT use the Prefer header
    mechanism for content negotiation.

2.2.  Examples

    The following examples illustrate the use of various preferences
    defined by this specification, as well as undefined extensions for
    strictly illustrative purposes:

    1.  Return a "202 Accepted" response for asynchronous processing if
    the response cannot be processed within 10 seconds.  An undefined
    "priority" preference is also specified:

      Prefer: return-asynch, wait=10;
      Prefer: priority=5;

Shouldn't that be:

      Prefer: return-asynch; wait=10
      Prefer: priority=5

???

3.  Preference Definitions

    The following subsections define an initial set of preferences.
    Additional preferences can be registered for convenience and/or to
    promote reuse by other applications.  This specification establishes
    an IANA registry of such relation types (see Section 4.1).

    Registered preference names MUST conform to the token rule, and MUST
    be compared character-by-character in a case-insensitive fashion.
    They SHOULD be appropriate to the specificity of the preference;
    i.e., if the semantics are highly specific to a particular
    application, the name should reflect that, so that more general names
    remain available for less specific use.

    Registered preferences MUST NOT constrain servers, clients or any
    intermediaries involved in the exchange and processing of a request
    to any behavior required for successful processing.  The use and
    application of a preference within a given request MUST be optional
    on the part of all participants.

3.1.  The "return-asynch" Preference

    The "return-asynch" preference indicates that the client prefers the
    server to respond asynchronously to a response.  For instance, in the
    case when the length of time it takes to generate a response will
    exceed some arbitrary threshold established by the server, the server
    can honor the return-asynch preference by returning either a "202
    Accepted" or "303 See Other" response.

...would be good to explain when to use what (not sure about when 303 
would be right).

3.4.  The "wait" Preference

    The "wait" preference can be used to establish an upper bound on the
    length of time, in seconds, the client is willing to wait for a
    response, after which the client might choose to abandon the request.
    In the case generating a response will take longer than the time
    specified, the server, or proxy, MAY choose to utilize an
    asynchronous processing model by returning, for example, "202
    Accepted" or "303 See Other" responses.

    ABNF:

      wait = "wait" BWS "=" BWS delta-seconds

    Clients specifying the "wait" preference SHOULD also use the Date
    header field, as specified in Section 9.2 of
    [I-D.ietf-httpbis-p2-semantics], within the request to establish the
    time at which the client began waiting for the completion of the
    request.  Failing to include a Date header field in the request would
    require the server to use the instant it received or began processing
    the request as the baseline for determining how long the client has
    been waiting which could yield unintended results.

I'm not totally convinced that taking the Date request header field into 
account is necessary given the additional complexity; what do others 
think?

3.5.  The "strict" and "lenient" Processing Preferences

Editorial: why are "strict" and "lenient" described in a single section, 
while "return-representation" and "return-minimal" are not?

    An example request specifying the "strict" preference:

      POST /collection HTTP/1.1
      Host: example.org
      Content-Type: text/plain
      Prefer: strict

    An example request specifying the "lenient" preference:

      POST /collection HTTP/1.1
      Host: example.org
      Content-Type: text/plain
      Prefer: lenient

I like examples, but too much is too much :-)

4.  IANA Considerations

    The 'Prefer' header field should be added to the Permanent Message
    Header Fields registry defined in [RFC3864]
    (http://www.iana.org/assignments/message-headers/perm-headers.html).

       Header field name: Prefer
       Applicable Protocol: HTTP
       Status:

"standard", right?

5.  Security Considerations

    Specific preferences requested by a client can introduce security
    considerations and concerns beyond those discussed in HTTP/1.1 Parts
    1 [I-D.ietf-httpbis-p1-messaging], 2 [I-D.ietf-httpbis-p2-semantics],
    3 [I-D.ietf-httpbis-p3-payload], 4 [I-D.ietf-httpbis-p4-conditional],

There is no spoon^h^h^h^h^hPart 3.

    5 [I-D.ietf-httpbis-p5-range], 6 [I-D.ietf-httpbis-p6-cache], and 7
    [I-D.ietf-httpbis-p7-auth].  Implementors must refer to the
    specifications and descriptions of each preference to determine the
    security considerations relevant to each.


Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Oct 2012 10:22:03 -0700

On 5 October 2012 08:12, Julian Reschke <[email-masked]> wrote:
> account is necessary given the additional complexity; what do others think?

I said as much in my GenART review:
http://www.ietf.org/mail-archive/web/gen-art/current/msg07790.html

Having had experience implementing this exact feature, relying on Date
isn't going to work.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Oct 2012 11:12:26 -0700

On 5 October 2012 10:42, James M Snell <[email-masked]> wrote:
> I could drop the Date header recommendation altogether and stress in the
> text that good clock synchronization and predictable latency is required for
> the wait preference to be used effectively.

The feature is useful, I agree.  The problem is that - as defined -
the server needs to guess something about the times on the client in
order to implement this reliably.

Relying on clock synchronization is not realistic.  Even in controlled
environments, errors are commonplace.

Even the simple case shows a problem:
  a: client sends request
  b: server receives request
  c: time passes
  d: server responds to request
  e: client receives response

You require that the time be a measure of a->e.  The server has no way
to determine what that time is.

An alternative would be to make the requirement apply to b->d.  That
is something that the server has direct control over.  The client then
gains a little extra work, but at least they are in a position to
measure a->b + d->e.  In any case, with low or predictable latency, I
doubt that the addition of a->b + d->e will have any significant
impact on whether the information is useful to the client.  Especially
given that times are expressed in seconds, not microseconds.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Oct 2012 14:18:38 -0700

An improvement.  Though the following doesn't read quite right to me:

  It is important to consider that there are many -- largely
  unpredictable -- factors that can influence the amount of time it
  takes a server to process a request. The period of time specified
  is not intended to be treated as a strictly defined "hard limit"
  but rather as a hint about the client's expectation.

I'm not sure that it's "mysterious forces" at the server that are the
issue in this design.  Nor is it the case that this would ever be a
hard limit.  As a preference, it's always option.  How about:

  Messages spend some time traversing the network and being
  processed by intermediaries.  This increases the time that a
  client awaits a response in addition to any time spent at a
  server.  A client that has strict timing requirements can estimate
  these factors and adjust the wait value accordingly.

Note that "intermediaries" could include the HTTP stack in both client
and server.

And maybe:

  As with other preferences, the wait preference could be ignored.
  Clients can abandon requests that take longer than they are
  prepared to wait.

--Martin

On 5 October 2012 11:28, James M Snell <[email-masked]> wrote:
> How about the following change:
>
> <snip>
>
>   length of time, in seconds, the client expects it will take the server
>   to process the request once it has been received. In the case that
>   generating a response will take longer than the time specified,
>   the server, or proxy, can choose to utilize an asynchronous processing
>   model by returning -- for example -- a "202 Accepted" response.
>
>   ABNF:
>   It is important to consider that there are many -- largely
>   unpredictable -- factors that can influence the amount of time it
>   takes a server to process a request. The period of time specified
>   is not intended to be treated as a strictly defined "hard limit"
>   but rather as a hint about the client's expectation.
>
>   For example, a server receiving the following request might choose
>   to respond asynchronously if processing the request will take longer
>   than 10 seconds:
>
>     Prefer: return-asynch, wait=10
>
>     {Data}
>
> </snip>
>
> On Fri, Oct 5, 2012 at 11:12 AM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: James M Snell <[email-masked]>
Date: Fri, 5 Oct 2012 10:42:10 -0700

I am certainly open to alternatives on this particular point. The wait
preference has proven to be quite useful in environments where the latency
is low and predicable and there is good clock synchronization between the
client and server. Such conditions can be easily achieved when the
deployment environment is well managed. It does not work so well,
obviously, for arbitrary web clients running on mobile devices talking to
arbitrary servers. I never really intended wait to be used within such
environments, however.

I could drop the Date header recommendation altogether and stress in the
text that good clock synchronization and predictable latency is required
for the wait preference to be used effectively.

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 5 Oct 2012 11:28:21 -0700

<snip>

  ABNF:

    {Data}

</snip>

On Fri, Oct 5, 2012 at 11:12 AM, Martin Thomson <[email-masked]>wrote:

> for

---

From: James M Snell <[email-masked]>
Date: Fri, 5 Oct 2012 14:26:36 -0700

That works for me.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Oct 2012 14:21:28 +0200

> see below for my (mostly editorial) feedback:

I note that there was no reply to this mail, and at least one problem is 

Best regards, Julian