WHATWG on 2024-03-25

07:31	<Adam Rice>	Chrome has started development on Private Network Access for WebSockets, which is going to require a preflight. As discussed in the following few messages after https://github.com/whatwg/websockets/issues/16#issuecomment-1926609805, we will probably need new `Access-Control-Allow-WebSocket` and `Access-Control-Request-WebSocket` headers. What's the right forum to propose and discuss those?
07:37	<sideshowbarker>	Adam Rice: Any reason not to just use the https://github.com/whatwg/fetch/issues tracker?
10:37	<annevk>	TabAtkins: algorithm="..." values in Bikeshed are just for disambiguation purposes, right? See https://github.com/whatwg/url/pull/826 for context. I guess I'll leave it unmerged for a bit so you can review. Fortunately adding these didn't reveal any variable name errors.
13:55	<TabAtkins>	TabAtkins: algorithm="..." values in Bikeshed are just for disambiguation purposes, right? Yes, tho they're also required to have variable colors kick in
14:21	<annevk>	TabAtkins: right, that's why it's worth adding them. (Although I also added them for algorithms that don't contain any variables, mainly for consistency.)
14:29	<TabAtkins>	I also use them for some useful styling, the little gray border, which I'm planning to add to the bikeshed stylesheet. Might want to look into putting it in whatwg as well
14:29	<TabAtkins>	Seems to really help in algorithm heavy sections to know the bounds of the text
14:41	<annevk>	TabAtkins: does the PR look okay btw?
15:02	<TabAtkins>	TabAtkins: does the PR look okay btw? Looks reasonable to me with a quick scan
15:32	<annevk>	I think at one point I was down to <25 issues for whatwg/url. Now it's 79.
16:53	<jub0bs>	Just checking my sanity here... Is there any case where a Fetch-compliant browser would include multiple `Access-Control-Request-Headers` headers in a preflight request? My understanding of CORS-preflight fetch (specifically step 5.2) tells me no, but I'd appreciate confirmation 🙏
16:56	<jub0bs>	For context, the reason I'm asking is that some libraries assume the presence of an arbitrary number of ACRH headers and do... funky things with them, leading to many unnecessary heap allocations. 😬
17:10	<annevk>	jub0bs: I guess middleware is not allowed to do the reverse of combine? And I guess with multiple headers you mean the equivalent of multiple H1 header lines for the same header name. If so, I don't think so.
17:16	<jub0bs>	annevk: Thanks for your reply. 😃 I'm actually asking regardless of what a middleware is "allowed" to do (I'm guessing you mean according to the HTTP spec). And I'm not sure what you mean by "H1 header", but what I mean by multiple ACRH header is something like `Origin: https://example.com Access-Control-Request-Headers: foo Access-Control-Request-Headers: bar Access-Control-Request-Headers: baz` I'd like to rely on the guarantee that there be at most one `Access-Control-Request-Headers` in the preflight request. I would just like confirmation that this guarantee is provided by the Fetch standard.
17:18	<jub0bs>	More context: in one of those CORS middleware libraries, a single malicious/spoofed 1Mb preflight request can cause 100+Mb of heap allocations, in part because that library caters for multiple ACRH headers in preflight requests.
17:19	<annevk>	I understood the question.
17:20	<jub0bs>	Thanks for confirming.