Subject: Re-review of draft-snell-http-prefer-15

From: Barry Leiba <[email-masked]>
Date: Sat, 13 Oct 2012 10:42:53 -0400

After some discussion on the httpbis mailing list, James made a significant
change to draft-snell-http-prefer-15, adding (back) the Preference-Applied
response header field.  See:
http://tools.ietf.org/rfcdiff?url2=draft-snell-http-prefer-15.txt

Because this happened after last call, I would like the copied communities
to re-review this in parallel with IESG Evaluation, and make further
comments on that particular change.

The document is on the 25 Oct telechat, so please post any comments by then.

Barry, sponsoring AD

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 14 Oct 2012 05:42:48 +1100

My .02:

* Technically, the requirement for including a Vary should include the option for using Vary: *; requiring Prefer in the Vary header is too constraining.

* Vary needs to be on *every* response from a resource that evidences negotiation, not those that just happen to be influenced by the Prefer header. 

* The examples section needs to show complete request and response messages, not just examples of the header field in isolation. This spec is not just defining a header, it's defining a protocol.

* "return-async" now seems like a less functional expression of "wait". Also, saying you'd *prefer* something to return async doesn't make much sense; if the request semantics can be honoured immediately and reflected in the response representation, why not allow so? 

I can imagine some protocols that want to tunnel over HTTP wanting to do so, but can't think of any sane use of HTTP that would. return-async can be dropped.

* I still don't see the use cases for Preference-Applied (see message just now on the thread that brought it back). I'm not going to fight it, but am -0.5 on it (as I think it introduces opportunities for people to abuse the mechanism).

Cheers,

On 14/10/2012, at 1:42 AM, Barry Leiba <[email-masked]> wrote:

> After some discussion on the httpbis mailing list, James made a significant change to draft-snell-http-prefer-15, adding (back) the Preference-Applied response header field.  See:
> Because this happened after last call, I would like the copied communities to re-review this in parallel with IESG Evaluation, and make further comments on that particular change.
> 

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

---

From: James M Snell <[email-masked]>
Date: Sat, 13 Oct 2012 12:00:48 -0700

On Sat, Oct 13, 2012 at 11:42 AM, Mark Nottingham <[email-masked]> wrote:

> My .02:
>
> * Technically, the requirement for including a Vary should include the
> option for using Vary: *; requiring Prefer in the Vary header is too
> constraining.
>
> * Vary needs to be on *every* response from a resource that evidences
> negotiation, not those that just happen to be influenced by the Prefer
> header.
>

A comment can be added in that "Vary: *" would also cover the requirement
here.

>
> * The examples section needs to show complete request and response
> messages, not just examples of the header field in isolation. This spec is
> not just defining a header, it's defining a protocol.
>
>
Noted but not sure it's critical since there are plenty of other examples
given throughout the document that show complete requests. It's a minor
addition, tho, that can be added into a final version.

> * "return-async" now seems like a less functional expression of "wait".
> Also, saying you'd *prefer* something to return async doesn't make much
> sense; if the request semantics can be honoured immediately and reflected
> in the response representation, why not allow so?
>
> I can imagine some protocols that want to tunnel over HTTP wanting to do
> so, but can't think of any sane use of HTTP that would. return-async can be
> dropped.
>
>
-1 ... in my use of this I have used return-asynch and wait together (e.g.
Prefer: return-asynch; wait=10)... if the server is able to process the
request in less than 10 seconds, it does so and responds synchronously. If
it cannot, it responds asynchronously. The mechanism works rather
effectively when dealing with long running processes. I respect that you
might not consider such use to be "sane" but it has proved useful
nevertheless.

- James

* I still don't see the use cases for Preference-Applied (see message just
> now on the thread that brought it back). I'm not going to fight it, but am
> -0.5 on it (as I think it introduces opportunities for people to abuse the
> mechanism).
>

> > After some discussion on the httpbis mailing list, James made a
> significant change to draft-snell-http-prefer-15, adding (back) the
> Preference-Applied response header field.  See:
> > Because this happened after last call, I would like the copied
> communities to re-review this in parallel with IESG Evaluation, and make
> further comments on that particular change.
> >
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 14 Oct 2012 06:05:43 +1100

On 14/10/2012, at 6:00 AM, James M Snell <[email-masked]> wrote:

> -1 ... in my use of this I have used return-asynch and wait together (e.g. Prefer: return-asynch; wait=10)... if the server is able to process the request in less than 10 seconds, it does so and responds synchronously. If it cannot, it responds asynchronously. The mechanism works rather effectively when dealing with long running processes. I respect that you might not consider such use to be "sane" but it has proved useful nevertheless.

Right, but what's the difference between:

  Prefer: wait=10
and
  Prefer: return-asynch, wait=10

? "return asynch" really says "give me a 202" which is nonsense; the client doesn't control the status code, the server does. 

Cheers,

P.S. I hate that "h" on "return-asynch"... :)

---

From: James M Snell <[email-masked]>
Date: Sat, 13 Oct 2012 12:11:28 -0700

On Sat, Oct 13, 2012 at 12:05 PM, Mark Nottingham <[email-masked]> wrote:

> > -1 ... in my use of this I have used return-asynch and wait together
> (e.g. Prefer: return-asynch; wait=10)... if the server is able to process
> the request in less than 10 seconds, it does so and responds synchronously.
> If it cannot, it responds asynchronously. The mechanism works rather
> ? "return asynch" really says "give me a 202" which is nonsense; the
> client doesn't control the status code, the server does.
>
>
That's why it's a Prefer header and not Expect. The server retains control.
"Prefer: wait=10" could just as easily result in the server simply throwing
up it's hands and saying, "sorry, can't do it"

> P.S. I hate that "h" on "return-asynch"... :)

Yeah yeah... me too. Only reason not to drop it would be some existing code
but known impls are limited enough right now that it shouldn't be a problem
really.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 14 Oct 2012 07:39:42 +1100

On 14/10/2012, at 6:11 AM, James M Snell <[email-masked]> wrote:

> That's why it's a Prefer header and not Expect. The server retains control. "Prefer: wait=10" could just as easily result in the server simply throwing up it's hands and saying, "sorry, can't do it"

And what does return-async(h) bring to the party?

The server can still throw up its hands with a 4xx or 5xx, and the client has to deal with that.

---

From: Jan Algermissen <[email-masked]>
Date: Sat, 13 Oct 2012 23:08:10 +0200

> And what does return-async(h) bring to the party?

I cannot see that either. In fact, I cannot even imagine a server paying attention to the '10', given the juggling between estimating the task duration and comparing to the wait time.

Maybe

  Prefer: wait

just does the job?

Jan

---

From: James M Snell <[email-masked]>
Date: Tue, 16 Oct 2012 12:33:34 -0700

On Sat, Oct 13, 2012 at 2:08 PM, Jan Algermissen <[email-masked]
> wrote:

> >> That's why it's a Prefer header and not Expect. The server retains
> control. "Prefer: wait=10" could just as easily result in the server simply
> throwing up it's hands and saying, "sorry, can't do it"
> >
> I cannot see that either. In fact, I cannot even imagine a server paying
> attention to the '10', given the juggling between estimating the task
> duration and comparing to the wait time.
>
> Maybe
>
>   Prefer: wait
>
> just does the job?
>

No, wait simply tells the server how long the client expects processing of
the request to take and does not communicate any information about the
preferred response. I could, for instance, have a theoretical "Prefer:
wait=120, respond-giveup" that could be interpreted as "I prefer you give
up if you can't process this request in less than 2 minutes".

- James