You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thanks for developing and maintaining this amazing library.
Description
I am trying use the full potential of HTTP/3 and QUIC by utilizing 0-RTT handshakes and inculde early data (HTTP/3 requests) in the 0-RTT handshakes. aioquic sends the Initial packet and 0-RTT packet as two separate UDP datagrams. This means that early data requests are not included in the transmitted datagram.
The problem seems to be how aioquic pads initial packets. aioquic adds PADDING frames to the initial packet. This fills the UDP datagram leaving no space for the 0-RTT packet anymore, which results in the 0-RTT packet being sent in the next datagram.
In order to solve this issue, aioquic should add padding to UDP datagrams instead of QUIC packets. UDP datagrams can be padded by adding zero bytes after all QUIC packets inside a UDP datagram. This UDP datagram padding works for datagrams containing only packets with long headers, because the long header features a length field. This UDP padding is used by other QUIC clients such as Firefox.
Reproducable example
importasynciofrompathlibimportPathimportsslfromurllib.parseimporturlparsefromaioquic.asyncio.clientimportconnectfromaioquic.h3.connectionimportH3_ALPNfromaioquic.quic.configurationimportQuicConfigurationfromexample_aioquic_http3_clientimportHttpClient# examples/http3_client.pyclassHttpClient0Rtt(HttpClient):
defconnect(self, addr) ->None:
self._quic.connect(addr, now=self._loop.time())
# Do not transmit handshake packets yet. We might want to add a 0-RTT request first.# self.transmit()asyncdefwait_connected(self) ->None:
""" Wait for the TLS handshake to complete. """assertself._connected_waiterisNone, "already awaiting connected"ifnotself._connected:
self._connected_waiter=self._loop.create_future()
# Transmit handshake packetsself.transmit()
awaitasyncio.shield(self._connected_waiter)
asyncdefget_session_ticket(url):
# Connect to server and store session ticket for 0-RTTsession_tickets= []
asyncwithconnect(
host=url.hostname,
port=url.portor443,
configuration=QuicConfiguration(
is_client=True,
alpn_protocols=H3_ALPN,
verify_mode=ssl.CERT_NONE,
secrets_log_file=open(Path(__file__).parent.parent/'quic_secrets.log', 'a'),
server_name=url.hostname,
),
create_protocol=HttpClient0Rtt,
session_ticket_handler=lambdat: session_tickets.append(t),
wait_connected=True
) asclient:
awaitclient.get(url.geturl())
returnsession_tickets[-1]
asyncdefmain() ->None:
url=urlparse('https://127.0.0.1:4431/')
session_ticket=awaitget_session_ticket(url)
# Try to send a HTTP/3 request in 0-RTT early dataasyncwithconnect(
host=url.hostname,
port=url.portor443,
configuration=QuicConfiguration(
is_client=True,
alpn_protocols=H3_ALPN,
verify_mode=ssl.CERT_NONE,
server_name=url.hostname,
session_ticket=session_ticket,
),
create_protocol=HttpClient0Rtt,
wait_connected=False
) asclient:
awaitclient.get(url.geturl())
if__name__=="__main__":
asyncio.run(main())
The text was updated successfully, but these errors were encountered:
First of all, thanks for developing and maintaining this amazing library.
Description
I am trying use the full potential of HTTP/3 and QUIC by utilizing 0-RTT handshakes and inculde early data (HTTP/3 requests) in the 0-RTT handshakes. aioquic sends the Initial packet and 0-RTT packet as two separate UDP datagrams. This means that early data requests are not included in the transmitted datagram.
The problem seems to be how aioquic pads initial packets. aioquic adds PADDING frames to the initial packet. This fills the UDP datagram leaving no space for the 0-RTT packet anymore, which results in the 0-RTT packet being sent in the next datagram.
In order to solve this issue, aioquic should add padding to UDP datagrams instead of QUIC packets. UDP datagrams can be padded by adding zero bytes after all QUIC packets inside a UDP datagram. This UDP datagram padding works for datagrams containing only packets with long headers, because the long header features a length field. This UDP padding is used by other QUIC clients such as Firefox.
Reproducable example
The text was updated successfully, but these errors were encountered: