Closed bashi closed 2 years ago
Thank you! I tested locally with a recent version of Google Chrome Canary, and things worked as expected.
Note, if you do something like
from random import choice
from string import digits
# ...
if isinstance(event, WebTransportStreamDataReceived):
if event.data != b'':
for c in iter(lambda: ''.join(choice(digits) for i in range(512)).encode('ascii'), b''): # replace '' with b'' for Python 3
if c is not None:
self._http._quic.send_stream_data(
event.stream_id, c, end_stream=False)
print(c)
the browser tab will crash 100% of the time.
We cannot really stream with WebTransport
.
Filed crbug.com/1266662. Thank you for the report.
@bashi Apparently some Chromium team members lobbied for me to get banned from bugs .chromium .org https://github.com/guest271314/banned/issues/5. That is not going to make the bugs I encounter during testing and let you folks know about magically go away from Chromium source code. In any event, additional information re the bug you filed:
gist of the code I tested with https://gist.github.com/guest271314/5f567517f94572e84026e76ec6e7cd89
Screen recording of the crash testing WebTransport
.
Screen recording using essentially the same Python code that outputs an endless stream to demonstrate the output I am expecting from STDOUT from Popen()
we can stream using PHP passthru()
.
stream.py
#!/usr/bin/env -S python3 -u
import sys
from random import choice
from string import digits
for chunk in iter(lambda: ''.join(choice(digits) for i in range(64)).encode('utf8'), b''):
if chunk is not None:
sys.stdout.buffer.write(chunk)
var abortable = new AbortController();
var {signal} = abortable;
fetch('./index.php', {method: 'post', body:'./stream.py', signal})
.then((r) => r.body)
.then((readable) => readable.pipeThrough(new TextDecoderStream()).pipeTo(new WritableStream({
write(v) {console.log(v)},
close() {console.log('Stream closed.')}
})).then(() => 'Done streaming.'))
.then(console.log)
.catch(console.warn);
The PHP I am using
<?php
header('Vary: Origin');
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: POST");
header("Content-Type: text/plain");
header("X-Powered-By:");
$input = fopen("php://input", "rb");
stream_set_blocking($input, 0);
echo passthru(stream_get_contents($input));
fclose($input);
exit(0);
?>
@yutakahirano I updated to Chromium after https://crrev.com/9d9ae7069814152be3747d8dd559cbc18fb0ad87. Unfortunately we are back to handshake error
Failed to establish a connection to https://localhost:4433/counter: net::ERR_METHOD_NOT_SUPPORTED.
The first time I encountered this error
Failed to establish a connection to https://localhost:4433/counter: net::ERR_QUIC_PROTOCOL_ERROR.QUIC_TOO_MANY_RTOS (Network blackhole detected).
Failed to establish a connection to https://localhost:4433/counter: net::ERR_QUIC_PROTOCOL_ERROR.QUIC_TOO_MANY_RTOS (Network blackhole detected).
Failed to establish a connection to https://localhost:4433/counter: net::ERR_QUIC_PROTOCOL_ERROR.QUIC_TOO_MANY_RTOS (Network blackhole detected).
Am encountering the same issue with the python server from the repo installed at https://webrtc.internaut.com:6161/counter and Canary 97.0.4691.0, running the live sample website or my own hosted version at https://webrtc.internaut.com/wt2/.
Note that the old python server works fine against https://webrtc.internaut.com/wt/ (which is based on the example in the WebTransport API specification).
The crash should be fixed at the lastest Chrome.
The connection failure should be fixed by #751.
The crash is fixed. It is still not possible to stream using WebTransport given the steps to reproduce in https://github.com/GoogleChrome/samples/pull/749#issuecomment-960433712 and https://bugs.chromium.org/p/chromium/issues/detail?id=1266662.
With Chrome Canary 98.0.4706.0, I can connect to the server.
Can you connect to the server, or do you have another problem?
I can connect to the python server without issues: https://webrtc.internaut.com/wt2/
The server is only running IPv4 so dual stack folks have reported problems but that is tangential to this bug.
The aioquic repository example is still broken, could use whatever you did here.
As a side note I still am not able to actually stream using WebTransport
. I did manage to send 65536 datagrams - which took 58 seconds - comparatively the same Python code STDOUT using PHP passthru()
took 3.8 seconds. https://groups.google.com/a/chromium.org/g/web-transport-dev/c/-nRKS9ws8tc. Obviously unacceptable. fetch()
wins every round so far.
Sorry, you posted many posts on multiple places and it's hard for me to grasp what's resolved and what's not.
I also ask you not to paste too much code in your emails and comments. You can create your own repository on github, place your code there and refer to the code in your emails and comments.
I am testing and trying to stream (a potentially infinite stream) using WebTransport, which I can do using fetch()
with PHP, and Native Messaging. There is no clear way to do that. I can see at terminal that the data is stored in some form of buffer in Python before ever reaching the browser. I will update the webtransport repository with the code I test, currently using datagram. When you find the time read the aioquic issue https://github.com/aiortc/aioquic/issues/226 (and update aioquic server code that currently has handshake error).
@yutakahirano @jeffposnick PTAL