- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 2 Apr 2022 13:46:41 +1100
- To: Guoye Zhang <guoye_zhang@apple.com>
- Cc: Roy Fielding <fielding@gbiv.com>, Marius Kleidl <marius@transloadit.com>, ietf-http-wg@w3.org
1xx is exposed in node.js and other JS HTTP implementations. I think what you mean is that it won't be implementable using JS in a browser. However, the right thing to do there may very well be to implement natively in the browser -- assuming that it has to be implementable without changes to browsers is an artificial constraint that may not be relevant. > On 2 Apr 2022, at 1:40 pm, Guoye Zhang <guoye_zhang@apple.com> wrote: > > > >> On Apr 1, 2022, at 6:30 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> >> >>> On 2 Apr 2022, at 6:30 am, Guoye Zhang <guoye_zhang@apple.com> wrote: >>> >>> Unfortunately, we’ve determined that 1xx response is too unreliable for critical information. Many middleboxes drop it, and most client frameworks do not expose it. Therefore we only use it for feature detection and none of the critical functionalities depend on it. >> >> That's something you should re-examine. When running over HTTPS and especially HTTP/2 (or /3), it's been found sufficiently reliable; e.g., see browsers' emerging deployments of 103 Early Hints. >> >> Cheers, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> > Yes, we have looked at Early Hints. It is a performance optimization and the loss of this response does not prevent any features from working. > > We hope that tus-v2 can be implemented either by the HTTP libraries themselves, or applications on top of it. For example, JavaScript `fetch` API does not expose 1xx responses at all. If we put any important info in intermediate responses, it would make the protocol unimplementable in JavaScript. > > Guoye -- Mark Nottingham https://www.mnot.net/
Received on Saturday, 2 April 2022 02:47:01 UTC