| 00:31 | <Domenic> | Pretty sure it has a "" path segment... let's see |
| 00:33 | <Domenic> | Yes: |
| 00:44 | <sideshowbarker> | I see |
| 00:44 | <sideshowbarker> | That's... unintuitive |
| 00:46 | <sideshowbarker> | So then the other question is, what's an example of a hierarchical URL which has the empty string for its `pathname`? |
| 00:47 | <sideshowbarker> | Is it possible for a hierarchical URL to ever have the empty string for its `pathname`? |
| 01:13 | <Domenic> | I don't think so |
| 02:38 | <Domenic> | annevk: hsivonen: Is XML5 actually feasible to replace XML parsers in browsers, or would introducing it run into the same problems of cross-ecosystem parser algorithm drift that causes us to disprefer making changes to the HTML parser? Is the idea that XML is used very little so we're less worried about the security issues? Or that the benefit is so large that it'd be worth the one-time churn? Or was the idea always for XML5 to be a third parser that sits alongside HTML and XML? |
| 06:39 | <sideshowbarker> | so now I’m wondering if there’s any real-world URL — for any scheme — that’ll ever have the empty string for its pathname |
| 06:40 | <sideshowbarker> | anything I can imagine that would have any real use is gotta have something after the : — and so, have a pathname |
| 06:40 | <sideshowbarker> | …I mean, any URL that identifies some real resource |
| 07:18 | <annevk> | Domenic: my idea was always that it would replace the XML parser and because it's generic and doesn't have language-specific knowledge it would be a one-time ecosystem cost |
| 10:05 | <sideshowbarker> | annevk: https://stackoverflow.com/questions/74301267/are-browser-credentials-resubmitted-when-a-javascript-fetch-redirects |
| 13:33 | <hsivonen> | annevk: hsivonen: Is XML5 actually feasible to replace XML parsers in browsers, or would introducing it run into the same problems of cross-ecosystem parser algorithm drift that causes us to disprefer making changes to the HTML parser? Is the idea that XML is used very little so we're less worried about the security issues? Or that the benefit is so large that it'd be worth the one-time churn? Or was the idea always for XML5 to be a third parser that sits alongside HTML and XML? p or HTML void elements, it wouldn't be subject to the same kind of drift. However, considering the general way of how people working on the Web Platform perceive XSS holes arising from syntax issues these days, perhaps the way XML 1.0 vs. XML5 is perceived has shifted a bit back towards XML 1.0. |
| 15:45 | <Sam Sneddon [:gsnedders]> | It would also move away from browser XML parsers being compatible with the rest of the ecosystem, which leads to potential exploits based on differential behaviour, which seems… likely bad. |
| 15:46 | <Sam Sneddon [:gsnedders]> | I don't expect realistically we'd be able to move the entire XML ecosystem, beyond browsers. For enough applications strict error-handling is viewed as a feature. |
| 15:52 | <sujaldev> | Is there anything the specifications can do to prevent sites from detecting browser developer tools and refusing to serve content if detected. |
| 15:55 | <jgraham> | No |
| 15:56 | <sujaldev> | Oh okay. |
| 15:57 | <jgraham> | For WebDriver-ish tools being detectable is considered a feature. For general devtools it seems highly likely that you'll always be able to figure out that they're running somehow if you're sufficiently motivated. |
| 15:59 | <sujaldev> | Shouldn't browsers try to prevent such detection? |
| 16:00 | <sujaldev> | Or are you saying that no matter what a browser does, devtools could always be detected? |
| 16:02 | <jgraham> | I think you could always detect them. |
| 16:02 | <sujaldev> | That is sad. Thanks for the info! |
| 20:39 | <jub0bs> | Hi there. I'm new here but, as I'm designing a principled CORS middleware library for Go, I have some questions. annevk suggested I ask them here (see https://github.com/whatwg/fetch/issues/1517#issuecomment-1291627075). Would that be alright? |
| 20:43 | <sideshowbarker> | howdy jub0bs — yup, you should go ahead and ask |
| 20:45 | <jub0bs> | I've got some concerns about this section of Jake's (otherwise very instructive!) post about CORS: https://jakearchibald.com/2021/cors/#conditionally-serving-cors-headers |
| 20:45 | <jub0bs> | In particular, this:
|
| 20:48 | <jub0bs> | This seems to imply that CORS middleware should vary the response based on the presence or absence of a cookie header, which is taken as a cue that the request is credentialed. But this is problematic, as the absence of a Cookie header doesn't guarantee that the request was anonymous (e.g. it could be using Authorization: Basic xxx). |
| 20:50 | <jub0bs> | Am I missing something? What do people think of this approach? |
| 20:55 | <jub0bs> | There's more. Further down, we're encouraged to responds with
|
| 20:57 | <sideshowbarker> | Jake Archibald: ↑ |
| 21:09 | <jub0bs> | I found a similar guideline in Brad Hill's W3C document from 2016: https://w3c.github.io/webappsec-cors-for-developers/#use-vary
|
| 22:08 | <Alice> | rego: https://github.com/whatwg/html/pull/8496 |