Re: Nice

+1.. a bit of explanation in the text would be good... in particular,
an implementer using the Nice header in an HTTP/2 request will need to
understand how Stream Priority and Nice really have nothing to do with
each other... that distinction could get lost if it's not made
explicit. Otherwise, this looks fine.

That said, I'm thinking that this could easily be implemented as a
Prefer token per http://tools.ietf.org/html/draft-snell-http-prefer-18

The HTTP Prefer header has already been accepted for publication as an
RFC (it's just waiting on the httpbis work to be completed). The
semantics for handling this seem to be appropriate for use with
Prefer.

Example:

  GET /m HTTP/1.1
  Host: device9710.example.net:11453
  Prefer: nice=2

It would also be interesting to see how this plays alongside other
Prefer directives like "wait" and "respond-async" ... For instance,
the a client could tell the intermediary that a request is of low
importance and that the intermediary can provide an asynchronous
response when it gets around to processing the request...

  GET /m HTTP/1.1
  Host: device970.example.net:11453
  Prefer: nice=3, wait=60, respond-async

Semantically this says, "Please treat this request as unimportant, if
you can't respond within 60 seconds, respond asynchronously."

- James



On Fri, Aug 16, 2013 at 11:14 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 16 August 2013 10:57, James M Snell <jasnell@gmail.com> wrote:
>> My immediate first response is: how does this overlap with Stream
>> priority.. I know this is a separate thing but it would be good to
>> make it clear how these intersect.
>
> These are orthogonal.  Stream priority is a way of saying that a given
> request has higher or lower relative latency requirements.  Whereas
> this marks a request as being not important enough to get through.
>
> I think that a little text on that subject makes sense.

Received on Friday, 16 August 2013 18:29:52 UTC