Sorry for slow response, I've been bogged down in many other tasks.
See inline....
On 12 February 2015 at 06:58, Edward Burns <edward.burns_at_oracle.com> wrote:
> Hello Greg,
>
> I recently read through h2 draft 16 and am in the process of submitting
> an editorial change pull request, I've filed issue 715 for this with
> pull request 08c4b13 for this. If you could advocate for this to be
> accepted I would appreciate it. I have some questions about the spec
> for you, some of which may cause another pull request.
>
> Section 3.2 Starting HTTP/2 for "https" URIs
>
> [...]
>
> Once TLS negotiation is complete, both the client and the server MUST
> send a connection preface (Section 3.5).
>
> Is the need for the connection preface unique to h2 or is it also
> present for h2c?
>
I believe the preface is for all http2 connections, no matter how they are
established. We certainly expect that to be the case.
> 4.3. Header Compression and Decompression
>
> [...]
>
> Header blocks MUST be transmitted as a contiguous sequence of frames,
> with no interleaved frames of any other type or from any other
> stream.
>
> Is this the source of your "HOL blocking is still a problem" assertion?
>
>
Yes. I see this as an encouragement for applications to move large data
into headers as they will neither be flow controlled or interleaved on a
shared connection.
The spec does not allow for interleaving of other frames in order to
simplify the header compression state that is kept between frames.
> 5.2.1. Flow Control Principles
>
> [...]
>
> 2. Flow control is based on window update frames. Receivers
> advertise how many octets they are prepared to receive on a
> stream and for the entire connection. This is a credit-based
> scheme.
>
> What is a credit-based scheme?
>
>
I'm not sure what that means either. But the mechanism works on a flow
control windows for the connection and for each stream. As each octet of
data is sent, the stream and connection windows are reduced. Once they
reach 0, no more data can be sent on either the stream or connection
(depending on which window hits 0). The receiving must send window updates
as it consumes the data to allow more data to be sent. The receiving may
increase the window beyond its initial size and may implement a variety of
strategies to reduce chatter eg. by using hysteresis etc.
> 5.3.4. Prioritization State Management
>
> When a stream is removed from the dependency tree, its dependencies
> can be moved to become dependent on the parent of the closed stream.
>
> Is "removed" equivalent to "closed" here?
>
>
yes.
> 5.5. Extending HTTP/2
>
> [...]
>
> Note that treating any frame other than DATA frames as flow controlled
> is such a change in semantics, and can only be done through
> negotiation.
>
> Was this text added at your request?
>
>
No. The extensions are so liberal that basically this says that all
parties must positively acknowledge them as if they don't then they are
almost certain to fail. Translation is - once HTTP/2 intermediaries are
deployed, there will never be any extensions.
> 6.2. HEADERS
>
> [...]
>
> Prioritization information in a HEADERS frame is logically equivalent
> to a separate PRIORITY frame, but inclusion in HEADERS avoids the
> potential for churn in stream prioritization when new streams are
> created.
>
> What is meant specifically by churn here?
>
You really don't want to ever change the priority of a request because it
can often be very difficult to do. For example if the priority is lowered
in a subsequent priority frame, that may be too late as the server may have
already dispatched the request to the servlet container - thus committing
resources to it. Conversely, if a request priority is increased, that may
also be too late as all the container resources (eg threads) may have been
committed to what are now lower priority requests.
The priority is a browser pipe dream. They really cannot expect to send a
server a bunch of requests in one order, but give priorities of a
completely different order and then expect the server to unscramble that
egg. Server priorities for allocating resources are unlikely to be able
to consider the clients rendering priorities to any significant extent.
>
> 6.5. SETTINGS
>
> [...]
>
> A SETTINGS frame with a length other than a multiple of 6 octets MUST
> be treated as a connection error (Section 5.4.1) of type
> FRAME_SIZE_ERROR.
>
> Why this 6 octet rule?
>
No idea really. I guess it is a sanity check (Simone??)
>
> 6.5.2. Defined SETTINGS Parameters
>
> [...]
>
> SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a
> peer of the maximum size of header list that the sender is
> prepared to accept, in octets.
>
> It seems to be a layering violation to have HPACK specific parameters
> here in this spec, don't you think?
>
>
Indeed. The intention here was really strange. There was the push on one
hand to support arbitrary large headers (un flow controlled and non
interleaved) vs the realisation that almost every implement will actually
have a hard limit. This setting was added as a bit of an after thought to
try to limit DOS attacks by sending arbitrarily large headers that never
actually end. The layering in HTTP2 is pretty much non existent as you
cannot interpret the base framing without knowing about HTTP2 specific
frame types (eg END_STREAM flag does not mean the end of the stream if it
comes in a HTTP HEADERS frame that is followed by CONTINUATION frames)!
> SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial
> window size (in octets) for stream level flow control. The
> initial value is 2^16-1 (65,535) octets.
>
> Perhaps this should be renamed SETTINGS_INITIAL_STREAM_WINDOW_SIZE?
>
true - but they have not been keen to change such things for a while now.
>
> 6.8. GOAWAY
>
> [...]
>
> There is an inherent race condition between an endpoint starting new
> streams and the remote sending a GOAWAY frame.
>
> Can you please explain this race condition to me?
>
Simply that a new stream can be created and sent while a GOAWAY frame is in
transit. Thus the receipt of a GOAWAY frame in itself is not sufficient to
tell if a server has acted on a request previously sent.... hence the last
stream id in the goaway frame.
>
> 7. Error Codes
>
> NO_ERROR (0x0): The associated condition is not as a result of an
> error. For example, a GOAWAY might include this code to indicate
> graceful shutdown of a connection.
>
> Why not make this a "must"? At least it a "should". A "might"? That's
> not even defined anywhere.
>
yup!
>
> 8.2.1. Push Requests
>
> [...]
>
> The PUSH_PROMISE frames sent by the server are sent on that explicit
> request's stream.
>
> Seems like this should be a MUST, no?
>
>
yup
> [...]
>
> The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to
> sending any frames that reference the promised responses. This
> avoids a race where clients issue requests prior to receiving any
> PUSH_PROMISE frames.
>
> Why is this not a MUST? Indeed the first text of the next section
> indicates this is indeed a MUST.
>
Probably should be a MUST. The only exception I can think of is that
PRIORITY frames are allowed pretty much at any time for any stream - even
prior or post the streams existence.
>
> 8.2.2. Push Responses
>
> [...]
>
> Once a client receives a PUSH_PROMISE frame and chooses to accept the
> pushed response, the client SHOULD NOT issue any requests for the
> promised response until after the promised stream has closed.
>
> How does the clint signal that it chooses to accept the pushed response?
> By not sending a GOAWAY? If so, that should be stated.
>
By not sending a stream reset. That is referred to else where, but
should have been explicitly mentioned here.
cheers
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.