W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #539: Priority from server to client

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Tue, 1 Jul 2014 12:22:47 -0400
Message-ID: <CAEn92TrJtr0uB8PxMOgaav8mfNCLmEux2f77gE6wPiFO_5SCuw@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
2) makes sense to me.

I don't think I understand the value of a server advertising to the client
what priority it's using to send a push-stream. By construction, at this
point the client hasn't yet integrated the stream into it's resource
loading flow, and can't make any prioritization decision. As soon as the
client discovers it's need for the resource, that would be an appropriate
time for it to send a PRIORITY to the server anyway.

Also, nothing prevents a client POST from depending on a server push
stream. In this case, a server-sent PRIORITY on that push stream already
has another meaning (it implicitly re-prioritizes the POST stream).

There may be value in relaxing the language in "5.3.5 Default Priorities"
to allow the server to assign an arbitrary initial weight (eg, because it
has knowledge the client doesn't yet have about load priority).


On Tue, Jul 1, 2014 at 10:27 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> Hervé is correct that the spec currently under-defines what it means when
> a PRIORITY frame goes from server to client.  However, there are a couple
> different options for what it might mean:
>   1) Server declares the priority it has placed on a stream.
>         + What if it's racing with a client-sent PRIORITY frame?
>   2) Server informing the client how the client ought to allocate resources
>         + Really only makes sense if the client has multiple large
> PUT/POSTs going on
>   3) Server can't send these.
>
> In NYC, we closed a related issue of having the server send its initial
> priority in the PUSH_PROMISE.  If we picked the first, that would be a
> natural corollary to the optional presence of PRIORITY in the HEADERS frame.
>
> I do think we should define one, just so there aren't different semantics
> on both sides of the connection.  I agree that the first makes me itch
> slightly.
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Tuesday, July 1, 2014 12:09 AM
> To: HTTP Working Group
> Subject: #539: Priority from server to client
>
> <https://github.com/http2/http2-spec/issues/539>
>
> I thought we'd discussed this a bit in NYC, but don't see anything in the
> minutes.
>
> How do people feel about this? Herve has made a proposal in a pull request:
>   <https://github.com/http2/http2-spec/pull/526/files>
>
> Personally, my .02 - I get nervous when a protocol element has different
> semantics depending on what direction it's travelling; e.g., Cache-Control
> turned out to be very confusing. It feels like that's going on here too; in
> one direction, it's a priority request, whereas in the other it seems like
> a declaration...
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
>
>
Received on Tuesday, 1 July 2014 16:23:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC