Re: [quicwg/base-drafts] Reduce HTTP/3 editorial dependence on HTTP/2 (#3264)

[Mike Bishop <[e-mail]>]

    QUIC is described in {{QUIC-TRANSPORT}}.  For a full description of HTTP/2, see
    {{!HTTP2=RFC7540}}.

Pretty clearly informative.

    Server push is an interaction mode introduced in HTTP/2 {{!HTTP2}} which permits
    a server to push a request-response exchange to a client in anticipation of the
    client making the indicated request.  This trades off network usage against a
    potential latency gain.  Several HTTP/3 frames are used to manage server push,
    such as PUSH_PROMISE, DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH.

*Probably* informative.

    A server that does not wish clients to reuse connections for a particular origin
    can indicate that it is not authoritative for a request by sending a 421
    (Misdirected Request) status code in response to the request (see Section 9.1.2
    of {{!HTTP2}}).
    
    The considerations discussed in Section 9.1 of {{!HTTP2}} also apply to the
    management of HTTP/3 connections.

Just referencing the definition of the existing response code could go either way.  Might want to copy over the connection management advice.

    As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with the ':'
    character (ASCII 0x3a) to convey the target URI, the method of the request, and
    the status code for the response.  These pseudo-header fields are defined in
    Section 8.1.2.3 and 8.1.2.4 of {{!HTTP2}}. Pseudo-header fields are not HTTP
    header fields.  Endpoints MUST NOT generate pseudo-header fields other than
    those defined in {{!HTTP2}}.  The restrictions on the use of pseudo-header
    fields in Section 8.1.2 of {{!HTTP2}} also apply to HTTP/3.  Messages which
    are considered malformed under these restrictions are handled as described in
    {{malformed}}.

This definitely would require copying text; it's a purely normative reference to a specific section of RFC 7540.

    To allow for better compression efficiency, the cookie header field {{!RFC6265}}
    MAY be split into separate header fields, each with one or more cookie-pairs,
    before compression. If a decompressed header list contains multiple cookie
    header fields, these MUST be concatenated before being passed into a non-HTTP/2,
    non-HTTP/3 context, as described in {{!HTTP2}}, Section 8.1.2.5.

This might require some text copying, or might be informative -- I'd have to read the section in more detail.

    A CONNECT request in HTTP/3 functions in the same manner as in HTTP/2. The
    request MUST be formatted as described in {{!HTTP2}}, Section 8.3. A CONNECT
    request that does not conform to these restrictions is malformed (see
    {{malformed}}). The request stream MUST NOT be closed at the end of the request.

This would require text copying.

    Server push is an interaction mode introduced in HTTP/2 {{!HTTP2}} which permits
    a server to push a request-response exchange to a client in anticipation of the
    client making the indicated request.  This trades off network usage against a
    potential latency gain.  HTTP/3 server push is similar to what is described in
    HTTP/2 {{!HTTP2}}, but uses different mechanisms.

This is purely informative.

    The header of the request message is carried by a PUSH_PROMISE frame (see
    {{frame-push-promise}}) on the request stream which generated the push. This
    allows the server push to be associated with a client request.  Promised
    requests MUST conform to the requirements in Section 8.2 of {{!HTTP2}}.

Requires text copying.

    The security considerations of HTTP/3 should be comparable to those of HTTP/2
    with TLS; the considerations from Section 10 of {{!HTTP2}} apply in addition to
    those listed here.

Seems kind of borderline -- this isn't really normative text, but you really should read the security considerations.

All the references in IANA Considerations and H2 Considerations are explicitly informative, so the switch would be easy there.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3264#issuecomment-571787247