jiebi/CodeConvo huggingface dataset:
have a route for the destination address, or if it is configured to reject a destination prefix by policy, or if the MTU of the outgoing link is lower than the size of the packet to be forwarded.  In such <del> scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP to signal the forwarding error to its peer. </del> <ins> scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP ICMPV6 to signal the forwarding error to its peer. Endpoints are free to select the most appropriate ICMP errors to send.  Some examples that are relevant for CONNECT-IP include: For invalid source addresses, send Destination Unreachable ICMPV6 with code 5, "Source address failed ingress/egress policy". For unroutable destination addresses, send Destination Unreachable ICMPV6 with a code 0, "No route to destination", or code 1, "Communication with destination administratively prohibited". For packets that cannot fit within the MTU of the outgoing link, send Packet Too Big ICMPV6. In order to receive these errors, endpoints need to be prepared to receive ICMP packets.  If an endpoint sends ROUTE_ADVERTISEMENT capsules, its routes SHOULD include an allowance for receiving ICMP messages.  If an endpoint does not send ROUTE_ADVERTISEMENT capsules, such as a client opening an IP flow through a proxy, it SHOULD process proxied ICMP packets from its peer in order to receive these errors.  Note that ICMP messages can originate from a source address different from that of the CONNECT-IP peer. </ins> 8.
contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its UDP proxying request.  However, implementors should note that such proxied packets may not be processed by the proxy if it responds to the request with a failure, or if the proxied packets are received by the proxy before the request. </del> <ins> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the proxy if it responds to the request with a failure, or if the proxied packets are received by the proxy before the request. </ins> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints
could send more data to an unwilling target than a CONNECT proxy. However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. <ins> While a proxy could potentially limit the number of UDP packets it is willing to forward until it has observed a response from the target, that is unlikely to provide any protection against denial of service attacks because such attacks target open UDP ports where the protocol running over UDP would respond, and that would be interpreted as willingness to accept UDP by the proxy. UDP sockets for UDP proxying have a different lifetime than TCP sockets for CONNECT, therefore implementors would be well served to follow the advice in handling if they base their UDP proxying implementation on a preexisting implementation of CONNECT. </ins> The security considerations described in HTTP-DGRAM also apply here.
Therefore it needs to respond to the request without waiting for a packet from the target.  However, if the target_host is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP <del> request.  If errors occur during this process (for example, a DNS resolution failure), the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy-Status" header field PROXY- STATUS. </del> <ins> request.  If errors occur during this process, the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy- Status" header field PROXY-STATUS (for example, if DNS resolution returns an error, the proxy can use the dns_error Proxy Error Type from PROXY-STATUS). </ins> UDP proxies can use connected UDP sockets if their operating system supports them, as that allows the UDP proxy to rely on the kernel to
servers that support UDP proxying ought to restrict its use to authenticated users. <ins> There exist software and network deployments that perform access control checks based on the source IP address of incoming requests. For example, some software allows unauthenticated configuration changes if they originated from 127.0.0.1.  Such software could be running on the same host as the UDP proxy, or in the same broadcast domain.  Proxied UDP traffic would then be received with a source IP address belonging to the UDP proxy.  If this source address is used for access control, UDP proxying clients could use the UDP proxy to escalate their access privileges beyond those they might otherwise have.  This could lead to unauthorized access by UDP proxying clients unless the UDP proxy disallows UDP proxying requests to vulnerable targets, such as localhost names and addresses, link-local addresses, the UDP proxy's own addresses, multicast and broadcast addresses. UDP proxies can use the destination_ip_prohibited Proxy Error Type from PROXY-STATUS when rejecting such requests. </ins> UDP proxies share many similarities to TCP CONNECT proxies when considering them as infrastructure for abuse to enable denial of service attacks.  Both can obfuscate the attacker's source address
3. <del> This document defines the "masque-udp" HTTP Upgrade Token. "masque- </del> <ins> This document defines the "connect-udp" HTTP Upgrade Token. "connect- </ins> udp" uses the Capsule Protocol as defined in HTTP-DGRAM. <del> A "masque-udp" request requests that the recipient establish a tunnel over a single HTTP stream to the destination target server identified by the "target_host" and "target_port" variables of the URI template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP. </del> <ins> A "connect-udp" request requests that the recipient establish a tunnel over a single HTTP stream to the destination target server identified by the "target_host" and "target_port" variables of the URI template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP. </ins> When sending its UDP proxying request, the client SHALL perform URI template expansion to determine the path and query of its request.
7.1. <del> This document will request IANA to register "masque-udp" in the HTTP </del> <ins> This document will request IANA to register "connect-udp" in the HTTP </ins> Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> masque-udp </del> <ins> connect-udp </ins> Proxying of UDP Payloads.
to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such limitations MUST use the default template which is defined as: <del> "https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </del> <ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </ins> 3.
"connect-udp". For example, if the client is configured with URI template <del> "https://proxy.example.org/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: </del> <ins> "https://proxy.example.org/.well-known/masque/ udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: </ins> 3.3.
This document will request IANA to register "connect-udp" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <ins> 8.2. This document will request IANA to register "masque/udp" in the Well- Known URIs Registry maintained at <<https://www.iana.org/assignments/ well-known-uris/well-known-uris.xhtml>>. </ins>
directions.  In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header <del> section.  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. </del> <ins> section.  (Note that only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections.)  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. </ins> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If a new HTTP Upgrade Token is only defined over
if they define semantics for such HTTP Datagrams and negotiate mutual support. <ins> 3.1. Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. 3.1.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. </ins> 4. This specification introduces the Capsule Protocol.  The Capsule
5. <del> Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. 5.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. 6. </del> Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see Section 11 of PRIORITY.
connection error of type H3_DATAGRAM_ERROR. HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's <del> send side is open.  Once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so related state can be released.  State MAY be kept for a short time to account for reordering.  Once the state is released, the received associated datagrams MUST be silently dropped. </del> <ins> send side is open.  If a datagram is received after the corresponding stream's receive side is closed, the received datagrams MUST be silently dropped. </ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop
An intermediary can reencode HTTP Datagrams as it forwards them.  In other words, an intermediary MAY send a DATAGRAM capsule to forward <del> an HTTP Datagram which was received in a QUIC DATAGRAM frame, and vice versa. </del> <ins> an HTTP Datagram that was received in a QUIC DATAGRAM frame, and vice versa.  Intermediaries MUST NOT perform this reencoding unless they have identified the use of the Capsule Protocol on the corresponding request stream; see capsule-protocol. </ins> Note that while DATAGRAM capsules that are sent on a stream are reliably delivered in order, intermediaries can reencode DATAGRAM
QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which
However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3 H3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. This design mimics the use of Stream Types in HTTP/3, which provide a demultiplexing identifier at the start of each unidirectional stream. </del> <ins> HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [2]) or on the GitHub repository which
the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 9. </del> <ins> 8. 8.1. This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: </ins> <del> 9.1. </del> <ins> 8.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 9.2. </del> <ins> 8.3. </ins> <del> This document will request IANA to register the "Datagram-Flow-Id" header field in the "Permanent Message Header Field Names" registry maintained at <<https://www.iana.org/assignments/message-headers>>. </del> <ins> This document establishes a registry for HTTP/3 frame type codes. The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: Type: A name or label for the capsule type. The value of the Capsule Type field (see capsule-frame) is a 62bit integer. An optional reference to a specification for the type.  This field MAY be empty. Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type. </ins> <del> 9.3. </del> <ins> This registry initially contains the following entries: </ins> <del> This document will request IANA to create an "HTTP Datagram Flow Parameters" registry.  Registrations in this registry MUST include the following fields: </del> <ins> 8.4. </ins> <del> The key of a parameter that is associated with a datagram flow list member (see header).  Keys MUST be valid structured field parameter keys (see Section 3.1.2 of STRUCT-FIELD). </del> <ins> REGISTER_DATAGRAM_CONTEXT capsules carry key-value pairs, see register-capsule.  This document will request IANA to create an "HTTP Datagram Context Extension Keys" registry.  Registrations in this registry MUST include the following fields: </ins> <del> A brief description of the parameter semantics, which MAY be a summary if a specification reference is provided. </del> <ins> The key (see register-capsule).  Keys MUST be valid tokens as defined in Section 3.2.6 of RFC7230. </ins> <del> This field MUST be either Yes or No.  Yes indicates that this parameter is the name of a named element (see header).  No indicates that it is a parameter that is not a name. </del> <ins> A brief description of the key semantics, which MAY be a summary if a specification reference is provided. </ins> An optional reference to a specification for the parameter.  This field MAY be empty.
CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL only be sent in client-initiated bidirectional streams. <del> Intermediaries MUST forward all received CAPSULE frames in their unmodified entirety on the same stream where it would forward DATA frames.  Intermediaries MUST NOT send any CAPSULE frames other than the ones it is forwarding.  Intermediaries respect the order of CAPSULE frames: if an intermediary receives two CAPSULE frames in a given order, it MUST forward them in the same order. </del> <ins> Intermediaries forward received CAPSULE frames on the same stream where it would forward DATA frames.  Each Capsule Type determines whether it is opaque or transparent to intermediaries: opaque capsules are forwarded unmodified while transparent ones can be parsed, added, or removed by intermediaries. </ins> This specification of CAPSULE currently uses HTTP/3 frame type 0xffcab5.  If this document is approved, a lower number will be
Data whose semantics depends on the Capsule Type. <ins> Unless otherwise specified, all Capsule Types are defined as opaque to intermediaries.  Intermediaries MUST forward all received opaque CAPSULE frames in their unmodified entirety.  Intermediaries MUST NOT send any opaque CAPSULE frames other than the ones it is forwarding. All Capsule Types defined in this document are opaque, with the exception of the DATAGRAM Capsule, see datagram-capsule.  Definitions of new Capsule Types MAY specify that the newly introduced type is transparent.  Intermediaries MUST treat unknown Capsule Types as opaque. Intermediaries respect the order of opaque CAPSULE frames: if an intermediary receives two opaque CAPSULE frames in a given order, it MUST forward them in the same order. </ins> Endpoints which receive a Capsule with an unknown Capsule Type MUST <del> silently drop that Capsule.  Intermediaries MUST forward Capsules, even if they do not know the Capsule Type or cannot parse the Capsule Data. </del> <ins> silently drop that Capsule. Receipt of a CAPSULE HTTP/3 Frame on a stream that is not a client- initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. </ins> 4.1.
how to process them from format also apply to HTTP/3 datagrams sent and received using the DATAGRAM capsule. <ins> The DATAGRAM Capsule is transparent to intermediaries, meaning that intermediaries MAY parse it and send DATAGRAM Capsules that they did not receive.  This allows an intermediary to reencode HTTP/3 Datagrams as it forwards them: in other words, an intermediary MAY send a DATAGRAM Capsule to forward an HTTP/3 Datagram which was received in a QUIC DATAGRAM frame, and vice versa. Note that while DATAGRAM capsules are sent on a stream, intermediaries can reencode HTTP/3 datagrams into QUIC DATAGRAM frames over the next hop, and those could be dropped.  Because of this, applications have to always consider HTTP/3 datagrams to be unreliable, even if they were initially sent in a capsule. </ins> 5. In order to facilitate extensibility of contexts, the