W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: [apps-discuss] Re-review of draft-snell-http-prefer-15

From: James M Snell <jasnell@gmail.com>
Date: Sat, 13 Oct 2012 12:11:28 -0700
Message-ID: <CABP7RbfOXNnqs-XVii8ZABDnFBX9rqrErtCbS=fHAZhbYUyZzQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Barry Leiba <barryleiba@computer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Apps Discuss <apps-discuss@ietf.org>
On Sat, Oct 13, 2012 at 12:05 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 14/10/2012, at 6:00 AM, James M Snell <jasnell@gmail.com> 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.
>
>
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"


> Cheers,
>
> 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


>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
Received on Saturday, 13 October 2012 19:12:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 13 October 2012 19:12:17 GMT