| 02:24 | <sideshowbarker> | Jake Archibald: sideshowbarker: https://github.com/whatwg/fetch/pull/1330 might be of interest |
| 02:25 | <sideshowbarker> | and don’t think anybody mentioned https://jakearchibald.com/2021/cors/ here yet, but everybody who cares anything about CORS should really read that |
| 06:47 | <Noam Rosenthal> | annevk: I think I found a good solution for the race-condition thingy (https://github.com/whatwg/fetch/pull/1311/files). Using existing queues for synchronization instead of introducing atomic lingo. Hope this works :) |
| 08:31 | <sideshowbarker> | Jake Archibald: By the way, about CORS pain points for developers, from what I’ve observed in the thousands of Stack Overflow CORS questions I’ve read, by far the single biggest pain point is that developers see a CORS error get logged in the devtools console and assume the cause is some problem with the CORS config on the server side — when in fact, the real problem is that the response is 400 or 500 error or other 4xx/5xx error |
| 08:32 | <sideshowbarker> | but, browsers don’t log those 4xx/5xx errors to the devtools console, so all that the developers see is the CORS error |
| 08:33 | <sideshowbarker> | so they reasonably assume the cause is some CORS-config issue, and then each of those developers spends literally hours trying to figure out what they got wrong in their CORS config |
| 08:34 | <hsivonen> | I've now tweaked https://github.com/whatwg/html/pull/7205 after reading it again after sleeping overnight between writing and reading. It could use spec-ese review. In particular, review of how the tree builder parts connect by reference to metaParser instead of minting a new concept for the thing that metaParser is. |
| 08:35 | <hsivonen> | I integrated the byte pattern analysis bits in this changeset, because it seemed silly not to. |
| 08:35 | <hsivonen> | The byte pattern analysis bits are intentionally vague enough to permit what Chrome does. |
| 08:36 | <sideshowbarker> | Jake Archibald: and multiply that by probably at least some hundreds of developers (but maybe even more like thousands) every day who go through that dance, and the result is a massive amount of time we are causing developers to waste by leading them to chase after problems in the wrong place |
| 08:56 | <Jake Archibald> | sideshowbarker: is it a preflight response in those cases, or also the main request? |
| 09:01 | <annevk> | sideshowbarker: geez Mike, that's a lot of comment |
| 09:02 | annevk | has some more tea |
| 09:12 | <sideshowbarker> | sideshowbarker: is it a preflight response in those cases, or also the main request? |
| 09:13 | <sideshowbarker> | sideshowbarker: geez Mike, that's a lot of comment |
| 09:13 | <annevk> | If the server gives a 4xx or a 5xx to a preflight, that does indicate there's a server issue though. |
| 09:13 | <Jake Archibald> | Depends if you count 404 as a server issue |
| 09:14 | <annevk> | And if it gives it to a non-preflight, but doesn't include the necessary CORS headers, that could be a server issue, depending on whether they want to partake. |
| 09:14 | <annevk> | Jake Archibald: I was assuming the request was made correctly. |
| 09:15 | <Jake Archibald> | I think the cases sideshowbarker is referring to involves an incorrect request, but the CORS error makes it look like an incorrect response. |
| 09:16 | <Jake Archibald> | Kinda funny that if you want the page to get access to a 404, the prelight needs to return a not-404 |
| 09:16 | <Jake Archibald> | I don't have a better idea though |
| 09:17 | <Jake Archibald> | (other than ignoring the status code) |
| 09:17 | <sideshowbarker> | by thy way, for “Access to 'foo' from origin 'bar' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status”, I don’t understand why that message doesn’t have “The HTTP status was 4xx” — that is, just make that message show the actual status code, rather than “does not have HTTP ok status”. Knowing the actual status code there would be way more helpful to developers. It would cut out the additional step they otherwise to do, to go to the Network tab and check the response. |
| 09:17 | <sideshowbarker> | I think the cases sideshowbarker is referring to involves an incorrect request, but the CORS error makes it look like an incorrect response. |
| 09:17 | <sideshowbarker> | very commonly, a 400 Bad Request |
| 09:18 | <sideshowbarker> | well, but that said, also quite commonly, a 500 or 502 |
| 09:19 | <sideshowbarker> | anway, I don’t understand why browsers can’t include the exact status code in every CORS errors message — or if they can, why they aren’t doing that |
| 09:20 | <sideshowbarker> | it would especially be more helpful for the error messages for the actual response (not just the preflight) |
| 09:21 | <annevk> | Well, we don't want to expose it directly to web content as that would violate SOP. |
| 09:21 | <sideshowbarker> | yeah I don’t mean exposing it to web content |
| 09:21 | <annevk> | We could expose it to DevTools probably and I think some might do that, but perhaps not to the extent that's desired. |
| 09:21 | <sideshowbarker> | I mean just logging it to the devtools console |
| 09:21 | <annevk> | Did you file bugs? I think we're pretty open to changing these messages. |
| 09:22 | <sideshowbarker> | well it’s not a spec issue, right? |
| 09:22 | <sideshowbarker> | it’s a browser issue |
| 09:22 | <annevk> | Right, https://bugzilla.mozilla.org/enter_bug.cgi?product=Core 🙂 |
| 09:22 | <sideshowbarker> | OK |
| 09:22 | <sideshowbarker> | yeah I will file bugs |
| 09:23 | <annevk> | Cool! DOM: Networking is the component for us btw |
| 09:23 | <sideshowbarker> | hai |
| 09:26 | <Jake Archibald> | I added a note about the 404 gotcha to the article https://github.com/jakearchibald/jakearchibald.com/commit/555bf50d039a510cba41b12dbd6b5606d5f09730 |
| 09:27 | <Jake Archibald> | sideshowbarker: can you file an issue for Chrome too? Or give me the issue you file for Mozilla and I'll copy it over |
| 09:28 | <sideshowbarker> | sideshowbarker: can you file an issue for Chrome too? Or give me the issue you file for Mozilla and I'll copy it over |
| 09:28 | <Jake Archibald> | Cheers |
| 09:28 | <Ms2ger 💉💉> | Looks like drafts.csswg.org is failing to serve tests again |
| 09:29 | <Jake Archibald> | Ms2ger 💉💉: the specs are gone too |
| 09:29 | <Ms2ger 💉💉> | Also I can't type |
| 09:29 | <Ms2ger 💉💉> | s/tests/specs/ |
| 09:29 | <Jake Archibald> | sideshowbarker: in case you need a demo of the preflight issue https://jakearchibald.com/2021/cors/playground/?prefillForm=1&requestMethod=GET&requestUseCORS=1&requestSendCredentials=&preflightStatus=404&preflightAllowOrigin=&preflightAllowCredentials=&preflightAllowMethods=&preflightAllowHeaders=&responseAllowOrigin=*&responseAllowCredentials=&responseExposeHeaders=&requestHeaderName=foo&requestHeaderValue=bar |
| 09:37 | <sideshowbarker> | Looks like drafts.csswg.org is failing to serve tests again |
| 09:37 | <Ms2ger 💉💉> | Where? csswg-drafts? |
| 09:44 | <sideshowbarker> | yeah https://github.com/w3c/csswg-drafts is where I have always raised it (N number of times…) |
| 09:52 | <annevk> | api.csswg.org (WHATWG uses it for Bikeshed) was also unreliable the other day |
| 14:00 | <jgraham> | If I'm at https://example.com#foo and I do location.href = location.href, what prevents that creating a new history entry? |
| 16:55 | <annevk> | jgraham: nothing in theory, but we did notice the other day that Chromium (and maybe WebKit) has an early return for setting hash to the same value; didn't really test if that applied to other setters though |
| 16:58 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=1733797 |