Martin Thomson wrote:
...
On 6 January 2015 at 05:13, Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx> 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