1986138 - WebTransport streams are unusable after the server sends STOP_SENDING

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P2)

Description

[alex]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36

Steps to reproduce:

When a bidirectional WebTransport stream is opened to a server, it's possible the server will send a STOP_SENDING frame.

This means they are ignoring any incoming data so we should not send any.

Firefox seems to treat this message as a fatal error and prevents the client from reading any incoming data. Chrome does not.

Here's a reproduction: https://github.com/achingbrain/webtransport-stop-sending

The server accepts WebTransport sessions, waits for an incoming stream, closes the stream for reading (e.g. sends STOP_SENDING) and then writes data into the stream.

The client just tries to read the incoming data.

You can run the go server with:

go get
npm start

It will print out some js code to run - you can paste it into https://codepen.io/pen/?editors=0012 or similar.

Actual results:

After the STOP_SENDING message is received, Firefox has the stream writer reject with:

"Writer closed with error" "WebTransportError" "WebTransportStream StopSending" 0 ""

It also rejects any attempts to read data with:

"Read errored" "TypeError" "Error in input stream" undefined ""

This is the bug.

OTOH Chrome closes the writer with:

"Writer closed with error" "WebTransportError" "Received STOP_SENDING." 0 "WebTransportError: Received STOP_SENDING."

but allows reading the data successfully.

Expected results:

Firefox should allow reading data from a stream that has had it's remote readable end closed, the same way Chrome does.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sunil Mayya]

Randell looks like we are deviating from the standard behavior here.
We need to fix it, not sure if this is high enough to be put in priority queue.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

I'd vote for priority queue for this one. Shouldn't be hard I think