Draft: draft-ietf-masque-h3-datagram

Commentary: This may be answered and I just missed it . After reading I think that for HTTP/1 and HTTP/2 Datagrams ( via capsules ) can only be sent for new methods / upgrade tokens . But it was n't clear to me if that same property was true for HTTP/3 . For example , would it be valid to send HTTP/3 datagrams along with a GET request ? If so , I think this means that for HTTP/3 a GET request could have both a body AND datagrams ? 
 That 's a very good point . If anything , we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET . I suspect drop or error are the most likely candidates here . 
 I vote for close the connection with error . The datagram has the relate to something in the request . If the request does n't or can not articulate a datagram use , the sender of datagram is probably broken or stupid . 
 Since datagrams are strongly associated with a stream , I think it 'd be more consistent to make this a stream error . Regardless , folks my want an extension to GET that allows sending datagrams with it , but it makes sense to require that this extension be negotiated via headers or settings first , so the semantics of such datagrams are agreed upon beforehand . So , I 'm supportive of making this a stream error , with the understanding that any extension can lift this requirement between consenting parties . 
 I 'd prefer to make people suffer but I could live with a stream error . Like you suggest , by letting people people agree on a change of requirements , we support extension . But the default of erroring helps datagram avoid the mess othat GET with body is . 
 Also , I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold 
 Ah yes . Sounds good , I 'll write up a PR for this once the design team PRs are landed . 
 Sounds good to me . An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here . ( A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams . On the other hand , confused peers gon na be confused and  's point about datagrams being strongly associated with a request is a good point ) 
 I think it should be a stream error to enable method - agnostic gateways and proxies , which may be multiplexing different clients ' traffic onto a single next - hop connection . 
 In , points out that Content - Type does n't make sense with the capsule protocol . Should we prohibit it ? 
 In , points out that status codes 204 , 205 , and 206 do n't make sense with the capsule protocol . Should we prohibit them ? 
 The spec currently says : In HTTP/1.x , the message content is generally delineated by the Content - Length header field or the Transfer - Encoding ; another request can follow on the same connection . One of the ( many ) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection , preventing any further requests from being made . The description attempts to be generic about method , but implicitly assumes an indefinite length stream of bytes which ( in H1 ) is only true of CONNECT or Upgrade . This concept is correct for what we have in mind , but the boundaries are n't crisply described right now . may have opinions . 
 The sentence right after the bit you pasted is : That constrains this to CONNECT / Upgrade / new methods . Is that not enough ? 
 I think " new methods " is probably the most questionable . It 's not clear to me that a new method can obtain the special behaviors of CONNECT . If it were restricted to upgrade tokens ( whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT ) , I think that would address the concern . 
 I believe what he means is this definition of a data stream only holds for CONNECT requests . There is no mechanism to extend that to new request methods since all other methods are required to have length - delimited data ( or no data ) . 
 Likewise , I do n't know of any reason we would want to support such extension methods in the future , since that is a known failure point for CONNECT . It is far simpler for a new method to require chunked or data frames . 
 Restricting this to extended CONNECT and Upgrade sounds reasonable to me 
 For  , the new protocol takes over after the current response is complete . Hence , the description above does n't really work for Upgrade either . 
 the intent of that text was to mean " after the current response is complete " - do you have a proposal for phrasing that would work better ? 
 Semantics says : I think is consistent with the definition of " data stream " in this document . ( And in fact uses the term " data stream " without defining it . ) That does n't seem to match deferring the new protocol until after the response . 
 I do n't think there is any technical distinction between the two descriptions ; it 's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure , whereas what follows Upgrade is a different protocol that might very well come back to this one ( as determined by the other protocol ) . 
 And point to This is an important part of the security analysis . 
 Only if you believe that the Sec- prefix is useful for the Capsule - Protocol header field . I do n't . 
 Sorry , I do n't mean that it 's the only thing that makes it work , merely that if were going to talk about how to analyze it , this is something we should say . 
 can you clarify your intent ? Your issue title starts with " Add to JS " but I suspect you did n't mean that we should modify the JavaScript specification . Would a note next to where the " Capsule - Protocol " header is defined resolve this ? 
 Aaargh . I meant " add to the security considerations " . 
 Thanks , that makes more sense :) Adding something to security considerations sounds good to me , I 'll add text to the . Note that this was filed on the wrong repository , is the droid you 're looking for . 
 So this assumption is useful in that it helps us avoid an analysis . Though my sense is that that analysis is n't especially difficult . The header field exists to enable datagram forwarding behaviour in an intermediary . We only have to show that there is no harm inflicted if a client engages that behaviour for requests , under the constraint that the client is otherwise authorized to make from a web context . The risk comes if this forwarding behaviour somehow generates different semantics as a result . As the same client also provides the stream of data that will be forwarded , it is trivial to see that they are already in a position to engage whatever semantics they choose . The only scenario that might benefit an attacker is where the elision of datagrams ( or things that look like them ) might be used to evade security protections that scan the stream of data . For an attack to be effective , those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary . This binding to CONNECT is a useful shortcut that means we do n't need to engage with all that stuff , which would n't be that easy to write down . ( This aversion to engagement is , I believe , a large part of why people want to slap " Sec- " on all new headers . ) 
 MT 's framing of this is helpful . Adding some security consideration about what might go wrong for an intermediary seems potentially useful . Spending text on why a browser is special in this regard seems less compelling to nme . 
 I was about to write a PR for this , but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens ( and not new methods ) then we 've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript . 
 LGTM thanks
This specification introduces the Capsule Protocol.  The Capsule
Protocol is a sequence of type-length-value tuples that new HTTP
Methods or new HTTP Upgrade Tokens can choose to use.  It allows
endpoints to reliably communicate request-related information end-to-
end on HTTP request streams, even in the presence of HTTP
intermediaries.  The Capsule Protocol can be used to exchange HTTP
Datagrams when HTTP is running over a transport that does not support
the QUIC DATAGRAM frame.
HTTP/3 datagrams MUST only be sent with an association to a stream
that supports semantics for HTTP Datagrams.  For example, existing
HTTP methods GET and POST do not define semantics for associated HTTP
Datagrams; therefore, HTTP/3 datagrams cannot be sent associated with
GET or POST request streams.  If an endpoint receives an HTTP/3
datagram associated with a method that has no known semantics for
HTTP Datagrams, it MUST abort the corresponding stream with
H3_GENERAL_PROTOCOL_ERROR.  Future extensions MAY remove these
requirements if they define semantics for such HTTP Datagrams and
negotiate mutual support.
This specification introduces the Capsule Protocol.  The Capsule
Protocol is a sequence of type-length-value tuples that new HTTP
Upgrade Tokens can choose to use.  It allows endpoints to reliably
communicate request-related information end-to-end on HTTP request
streams, even in the presence of HTTP intermediaries.  The Capsule
Protocol can be used to exchange HTTP Datagrams when HTTP is running
over a transport that does not support the QUIC DATAGRAM frame.
Note that use of the Capsule Protocol is not required to use HTTP
Datagrams.  If a new HTTP Method or Upgrade Token is only defined
over transports that support QUIC DATAGRAM frames, they might not
need a stream encoding.  Additionally, definitions of new HTTP
Methods or of new HTTP Upgrade Tokens can use HTTP Datagrams with
their own data stream protocol.  However, new HTTP Method or Upgrade
Tokens SHOULD use the Capsule Protocol unless they have a good reason
not to.
Note that use of the Capsule Protocol is not required to use HTTP
Datagrams.  If a new HTTP Upgrade Token is only defined over
transports that support QUIC DATAGRAM frames, they might not need a
stream encoding.  Additionally, definitions of new HTTP Upgrade
Tokens can use HTTP Datagrams with their own data stream protocol.
However, new HTTP Upgrade Tokens that wish to use HTTP Datagrams
SHOULD use the Capsule Protocol unless they have a good reason not
to.
By virtue of the definition of the data stream, the Capsule Protocol
is not in use on responses unless the response includes a 2xx
(Successful) status code.  The Capsule Protocol MUST NOT be used with
messages that contain Content-Length or Transfer-Encoding header
fields.
Definitions of new HTTP Methods or of new HTTP Upgrade Tokens that
use the Capsule Protocol MAY use the Capsule-Protocol header field to
simplify intermediary processing.
By virtue of the definition of the data stream, the Capsule Protocol
is not in use on responses unless the response includes a 2xx
(Successful) status code.
The Capsule Protocol MUST NOT be used with messages that contain
Content-Length, Content-Type, or Transfer-Encoding header fields.
Additionally, HTTP status codes 204 (No Content), 205 (Reset
Content), and 206 (Partial Content) MUST NOT be sent on responses
that use the Capsule Protocol.
Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol
MAY use the Capsule-Protocol header field to simplify intermediary
processing.
Endpoints indicate that the Capsule Protocol is in use on the data
stream by sending the Capsule-Protocol header field with a value of
?1.  A Capsule-Protocol header field with a value of ?0 has the same
semantics as when the header is not present.  Intermediaries MAY use
this header field to allow processing of HTTP Datagrams for unknown
HTTP methods or unknown HTTP Upgrade Tokens.
Endpoints indicate that the Capsule Protocol is in use on the data
stream by sending the Capsule-Protocol header field with a value of
?1.  A Capsule-Protocol header field with a value of ?0 has the same
semantics as when the header is not present.  Intermediaries MAY use
this header field to allow processing of HTTP Datagrams for unknown
HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade
or Extended CONNECT.
Since use of the Capsule Protocol is restricted to new HTTP Upgrade
Tokens, it is not accessible from Web Platform APIs (such as those
commonly accessed via JavaScript in web browsers).