421 and upload streams

[annevk]

Per #497 browsers implement 421. What does a 421 mean for an upload stream? Would we reveal the 421 to the caller after streaming completed?

Would clients that support early responses cancel the stream in addition?

cc @whatwg/http @yutakahirano

[yoichio]

Since ReadableStream is not replayable, 421 handling should be referred to the web author.

I guess supporting early responses cancel is hard as same as bidirectional support given Chromium starts response handling after whole request body sending.
cc @MattMenke2

[MattMenke2]

I'm no expert on the mechanics of sockets, but if we write and the socket is half-closed by the other end, without reading from it, my recollection is we tend to get connection resets, as opposed connection closed notifications. This behavior is observed across all platforms.

Once Windows notifies a consumer of a connection reset, you can no longer read from the socket, even if there was a 421 response pending. So just trying to read from a socket after uploading the request body fails, which would be much simpler than supporting full duplex sockets, won't give us a 421 response on Windows. On other platforms, we do actually read from the body on connection resets of upload attempts, and return 4xx/5xx responses, if we get them.

Note that this only applies to H1, I'm not sure what H2/QUIC do in this case, or if they even have an analog of half-closed sockets.

[yoichio]

Ping @annevk ?

[annevk]

I don't really have a stake in the outcome, but when we pass it on to the web developer (and when we retry) needs to be clear.

[yoichio]

If fetch upload failed, promise reject is called. If it succeeded and server returns 421, the web author gets 421.

[annevk]

I meant in the specification. 😊

[yoichio]

I don't understand yet what is special and unclear about 421 specification and the upload stream.
https://tools.ietf.org/html/rfc7540#section-9.1.2

[annevk]

Well, the request cannot be retried and therefore the 421 is forwarded to the application, whereas in other cases retrying is allowed. (I haven't tested what browsers do with it in general though.)

[yoichio]

I confirmed that both Chrome and Firefox retried the request once upon the 421 response for simple string fetch except
only Chrome prompted POST <url> 421 (Misdirected Request) error in devtool.

As fetch() fails on redirect resolution, how about
specifying "fetch() fails with the promise-error "Browser tried to retry the request on 421 but Stream can not be replayed" " as well?
or
As the IETF spec states "Clients receiving a 421 (Misdirected Request) response from a server MAY retry the request", not retrying
anything is also valid behavior. So no spec update is needed?

[annevk]

I think we should require retrying (similar to how we require redirects to be followed, etc.) and forbid it when a request body is a stream.

[yoichio]

I agree with not retrying when a request body is a stream.
I'm not sure if we should change the spec from "MAY" to "SHOULD" about other body's.

[annevk]

I'm saying MUST. Fetch is defining a type of client after all. I suppose we could make it less strict initially, but if every browser already does it I don't see why we would.

[yoichio]

Discussing the relation between 421 response and other body fetching is out of this issue blocking upload-streaming.

[yoichio]

Ping?

[annevk]

@yoichio ping for what?

[yoichio]

The current spec states "Clients receiving a 421 (Misdirected Request) response from a server MAY retry the request".
You're suggesting "___ MUST retry the request if the body is not streaming", right?

[annevk]

Right, because Fetch defines a particular type of client that ideally all behave the same.

[yoichio]

I overlooked the auxiliary verbs meaning: MAY is absolutely optional.

If changing the MAY to MUST is required to mean we must not retry streams body, I agree with you.

[yoichio]

Anne, what do you think of my above comment?

[annevk]

I'm not entirely sure what it means. What I think needs to happen is that Fetch mandates a particular behavior in response to 421 responses for all types of requests Fetch can make.

[yoichio]

Fetch mandates a particular behavior in response to 421 responses for all types of requests Fetch can make.

A particular behavior means a same action?
As we're discussing at #538, fetch doesn't retry if the body is stream to 30X responses.

[annevk]

Sorry, I did phrase that awkwardly. I meant that we should specify how to react to 421 responses for all requests. And "how" can be different depending on the type of request. E.g., if request's body is a stream, we return the response. If it's not, we refetch. (Similar indeed to how the specification details how to deal with 1XX and 304 for instance.)

[yoichio]

Thanks for clarifying that.

I'm not familiar with the spec grammar and writing.
How about rewriting the current spec with

If the body is not streaming, clients receiving a 421 (Misdirected Request) response from a server MUSTY retry the request.
If the body is streaming, clients receiving a 421 (Misdirected Request) response from a server MUSTY not retry the request.

?
and which spec (rfc7540 or whatwg/fetch) should be updated?

[annevk]

This would have to be in Fetch as browser considerations for 421 are not universal. I suspect it would be easiest for you to reach out to @yutakahirano for advice on how to go about it.

[yutakahirano]

@yoichio, last year we discussed this and IIRC you were willing to handle this issue, so I assigned this issue to you.

Please let me know if you need any help.

[yoichio]

Yes. I'll pull-request.

[annevk]

Closed by c5eb621 (#1141).