Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

[Julian Reschke <[e-mail]>]

Martin Thomson wrote:
> ...
> On 6 January 2015 at 05:13, Stefan Eissing <[e-mail]> wrote:
 > ...
>> 2. PUSH_PROMISE and header completeness
>> How are cache sensitive headers like "Authorization" handled in PUSH_PROMISE request headers? If simply left out, the client could store pushed resources in a cache where they do not belong. Should servers use extra Cache-Control directives in such pushed responses?
>
> This is part of the same sort of advice that your first question
> touches on: how do you effectively implement feature X.  Here, the
> rules are pretty easy to infer.  If you have a resource that would
> send Vary for a header field that the server cannot produce on its own
> then server push probably won't work.  Authorization is a great
> example.  The server might be able to produce *some* Authorization
> headers, particularly if one was in the request that the push is
> associated with though.
> ...

But then varying on "Authorization" does *not* require setting "Vary", 
because that aspect is baked into the protocol. (And some impls do the 
same thing for "Cookie" although not required by the spec).

Maybe this indicates that we just need more prose here.

>> Related: how is the role of the ACCEPT-* request headers? Should a client reject PUSH_PROMISE with request headers that does not match its own ACCEPT-* preferences? What if it uses ACCEPT-* and the PUSH_PROMISE is lacking those? Or the other way around?
>
> The same applies here.  A client uses the rules in Section 4 of RFC
> 7234 to determine whether a cached response can be used to satisfy its
> request.  If a client sends Accept: x/y and a server has pushed a
> response that included Vary: Accept and a content type that didn't
> match the clients preferred Accept header field, then the client
> should probably make a request rather than use the push.

This seems less of a problem than the one before as the HTTP responses 
are supposed to be self-descriptive, and clients *in general* an not 
assume that the server follows their preferences wrt Accept-*.

>> 3. Clarification on server-initiated push?
>> In discussions with colleagues some had the notion that HTTP2 would allow server initiated "requests". My reading of the draft is that this is not really the case. Server pushes are only defined for streams opened by the client.
>> - Is this the correct reading of the spec?
>> - If yes, has HTTP2 any advise how to best do long polling or what is the recommended alternative?
>
> Patrick has addressed that.  If you want a worked example of
> "long-polling" in HTTP/2, see
> https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html

Understood, but again it might be good if the spec actually was a bit 
clearer about this.

>> 4. SETTINGS_MAX_HEADER_LIST_SIZE as advisory
>> It seems undefined what a client (library) should do with it. Will this not give rise to interop problems if one client respects it and fails requests immediately while another does no checks and sends them anyway? MUST a peer that announces a limit always reply with 431 to requests that exceed it?
>
> Yes, this is a little nebulous, but intentionally.  If you consider an
> end-to-end protocol with multiple hops, the value that is actually
> enforced is the lowest value from all of the servers in the path of a
> request.  Since each request might follow different paths, the best
> that *this* protocol can do is provide information on the value
> enforced by the next hop (who knows if the next hop is even HTTP/2).
>
> The server is not required to send 431 if the size exceeds this: maybe
> some resources can handle streamed header fields, maybe some resources
> are forwarded to different origin servers.
>
> If you can't think of a concrete action to take based on this setting,
> I would ignore it.

Do we have any implementations that actually do something with this setting?

> ...
>> 7. Opinion: Chapter 9.1 Limitation to single connection
>> Have we not been here before? In the past, such SHOULD NOTs have not been very helpful. (Most likely already discussed heavily on the list...no strong feelings about this. It will be ignored anyway if not proving useful.)
>
> Indeed we have.  And when HTTP/1.1 advised a limit of 2 connections,
> that was done despite the fact that it was introducing a real
> limitation on the usability of the protocol.  2 wasn't a special
> number, it was just something someone made up (as is 6); 1 is one of
> the three important numbers, not an arbitrary choice.  Here, we have
> no such limitation because there is no corresponding limit on
> concurrency within the protocol.  There are still transport-level
> limitations (INIT_CWND, for instance), but I think some people expect
> to be lifting those over time.  I think that the working group is
> firmly intent in making this one stick.
> ...

Thread start: 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0147.html>

Ticket: <https://github.com/http2/http2-spec/issues/529>

I'm not very happy about the SHOULD, as we have heard about situations 
where it most definitively will be violated, see for instance William 
Chan in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0297.html>.

Best regards, Julian