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:00:48 -0700
Message-ID: <CABP7RbfdwHRGugepnZvRATq-wE7buuY3xSUEbRV+prp1Gy87BA@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 11:42 AM, Mark Nottingham <mnot@mnot.net> 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).
>


> Cheers,
>
>
>
> On 14/10/2012, at 1:42 AM, Barry Leiba <barryleiba@computer.org> 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:
> > 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
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
Received on Saturday, 13 October 2012 19:01:36 GMT

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