| 00:29 | <MikeSmith> | domfarolino: I think what the Fetch spec requires browsers to expose in this case is an “opaque filtered response” https://fetch.spec.whatwg.org/#concept-filtered-response-opaque |
| 00:29 | <MikeSmith> | > An opaque filtered response is a filtered response whose type is "opaque", url list is the empty list, status is 0, status message is the empty byte sequence, header list is empty, body is null, and trailer is empty. |
| 00:31 | <MikeSmith> | because the “response tainting” is "opaque" https://fetch.spec.whatwg.org/#concept-request-response-tainting |
| 00:32 | <MikeSmith> | and the response tainting is "opaque" because the mode is "no-cors" |
| 00:33 | <MikeSmith> | and the mode is "no-cors" because that is the default unless some other part of the fetch algorithm sets it to something else |
| 00:33 | <MikeSmith> | https://fetch.spec.whatwg.org/#concept-request-mode |
| 00:34 | <MikeSmith> | the possible modes are "same-origin", "cors", "no-cors", "navigate", or "websocket" |
| 00:35 | <MikeSmith> | and since this is not a same-origin fetch, nor a navigation, nor a websocket fetch, nor a CORS-enabled fetch, the mode remains set at the default "no-cors" |
| 00:44 | <domfarolino> | MikeSmith ok so does all that apply even though im using a script tag for the loading and not making a request with fetch? |
| 00:46 | <domfarolino> | Even if so, not sure why it would be opaque? It is a CORS-enabled request (since I'm using crossorigin attr on script tag) |
| 00:52 | <MikeSmith> | the Fetch spec defines the primitives for all fetches, regardless of whether they ' |
| 00:53 | <MikeSmith> | *regardless of whether they’re done usin the fetch() method or if instead the UA is initiating the fetch (instead of it being initiated from JS) |
| 00:54 | <MikeSmith> | for <script src> fetches the HTML spec references the fetch algorithm with certain settings for each of the hooks |
| 00:54 | <MikeSmith> | but yeah if you’re setting the crossorigin attribute then it is not doing a no-cors request |
| 00:55 | <MikeSmith> | and then there’s a different part of the spec that defines what kind of response gets returned |
| 00:55 | <MikeSmith> | gimme a minute to find it |
| 00:59 | <MikeSmith> | if the response is considered a “network error” as defined by the Fetch spec, then: |
| 00:59 | <MikeSmith> | > A response whose type is "error" is known as a network error. |
| 00:59 | <MikeSmith> | A network error is a response whose status is always 0, status message is always the empty byte sequence, header list is always empty, body is always null, and trailer is always empty. |
| 00:59 | <MikeSmith> | https://fetch.spec.whatwg.org/#concept-network-error |
| 01:00 | <MikeSmith> | ...which is essentially (or maybe exactly) the same response characteristics as an “opaque filtered response” |
| 01:40 | <domfarolino> | hmm ok |
| 01:46 | <domfarolino> | Only thing is, the kind of error I'm talking about is like a scripting error, after fetching has been complete (throw new Error()...) so the way the DOM handles JS errors kind of depends on how it was fetched, no matter how long after it was fetched. With that being said, I can't tell if the only elaboration on the connection between the way a script was |
| 01:46 | <domfarolino> | fetched and how the DOM handles its errors is in the `crossorigin` section of the HTML spec or if there is more elsewhere. cc Domenic |
| 01:48 | <domfarolino> | I guess if it is not elaborated on elsewhere, that could explain the differences I see in the Chrome and FF outputs |
| 01:48 | <domfarolino> | thanks for the info MikeSmith ! |
| 02:15 | <MikeSmith> | cheers |
| 04:25 | <Domenic> | domfarolino: this is governed by https://html.spec.whatwg.org/#report-the-error; see especially "muted errors" |
| 04:25 | <domfarolino> | oh no...should've gone multipage lol |
| 04:25 | <Domenic> | Whether a script has "muted errors" set does end up being determined whether the response is CORS-cross-origin |
| 04:26 | <Domenic> | i.e., whether the response's type is "opaque" or "opaqueredirect" |
| 04:32 | <domfarolino> | Domenic: ok I think I get that. So a script fetched with crossorigin attribute (via CORS) has an opaque (or opaqueredirect) response type? |
| 04:33 | <Domenic> | domfarolino: the opposite, I believe. A script fetched with the crossorigin attribute will have a response type "cors" |
| 04:34 | <Domenic> | so it'll be CORS-same-origin, so the muted errors flag will be unset |
| 04:37 | <domfarolino> | Oh ok...so omitting the crossorigin attribute is where we get opaque and opaqueredirect response types?...and hence a script with muted errors? |
| 04:38 | <Domenic> | Yep |
| 04:38 | <Domenic> | (But, if you add the crossorigin attribute, your script needs to have the appropriate CORS headers when it's cross-origin) |
| 04:42 | <domfarolino> | Right. So I always understood (without really digging in admittedly) opaque responses to be ones in which the actual meat of the response is invisible to the user. In fact, just quickly looking at the fetch spec now it says that an opaque filtered response has body=null, empty header list, etc...but how is this so, if I can see all of this in the network |
| 04:42 | <domfarolino> | tab? |
| 04:43 | <domfarolino> | "this", being all the data of a logged network request triggered from <script src="example.com/app.js"></script>; (no crossorigin attr, so opaque response right?) |
| 04:43 | <domfarolino> | Domenic: source: https://fetch.spec.whatwg.org/#concept-filtered-response-opaque |
| 04:44 | <Domenic> | Oh, that's easy. Dev tools have special powers. |
| 04:44 | <Domenic> | The important thing is you can't write code in your web page to read the contents. |
| 04:44 | <domfarolino> | Haha alright....yes! that second message is what I was about to say |
| 04:47 | <domfarolino> | Domenic: Sorry one more thing! So I couldn't get FF to show me an error message of "Script error" via running the following gist locally https://gist.github.com/domfarolino/28725582270679b9e17fa74922cbfd65 whereas Chrome was properly muting errors. |
| 04:47 | <Domenic> | Yeah, I'm not sure what's up with that; Firefox may be going against the spec. |
| 04:48 | <domfarolino> | Gotcha..didn't know if my reproduction was bogus or not..Alright I may look into filing a bug I guess |
| 04:48 | <Domenic> | I assume errorjs.js is adding a window.onerror handler? |
| 04:49 | <domfarolino> | errorjs.js has the exact same contents as the script loaded above it actually |
| 04:49 | <domfarolino> | so I guess I'm adding the handler twice...which I didn't think about |
| 04:50 | <Domenic> | Interesting... |
| 04:50 | <Domenic> | I guess it should override it |
| 04:50 | <Domenic> | So it should still be muted |
| 04:51 | <Domenic> | although hmm the function redeclarations for a/b/c might confuse things... |
| 04:51 | <domfarolino> | Ah true. I should change it up then. Maybe add the handler inline, and rename all functions. Regardless, Chrome gives me two different outputs in window.onerror...one muted, one not. FF gives both unmuted |
| 04:52 | <Domenic> | Yeah, presumably there's some interop bug here, although it's a bit harder to determine who's wrong. |
| 04:52 | <Domenic> | Anyway, bedtime for me :) |
| 04:52 | <domfarolino> | Thanks for the info. gn |
| 06:22 | <MikeSmith> | domfarolino: thinking about the was CORS works, the fact you can always see a response in devtools is expected |
| 06:23 | <MikeSmith> | because the browser is what enforces cross-origin restrictions, not servers |
| 06:24 | <MikeSmith> | generally if you can get a response from a server using any other client, curl or whatever, then the browser is going to get a response too |
| 06:24 | <domfarolino> | Right, I just didn't know how far that obfuscation reach was. As in...is both the user of the browser AND the site code that does not have access to opaque responses OR JUST the site code (meaning devtools can see all). But this was a naive thought anyways |
| 06:24 | <domfarolino> | Yes the curl is a good examp |
| 06:25 | <MikeSmith> | yeah just the site code can’t see it |
| 06:25 | <MikeSmith> | but it’s not a naive thought |
| 06:26 | <MikeSmith> | because I think the CORS protocol is kind of non-intuitive |
| 06:27 | <MikeSmith> | I think most people are surprised to find out they can see a response in devtools but their code can’t get to it |
| 06:27 | <domfarolino> | It is certainly kind of odd. Always struck me as odd that the browser was the one managing the security, not the server (prized resource)...but then I learned about preflighting which makes more sense. |
| 06:27 | <domfarolino> | Yeah that makes sense |
| 06:27 | <MikeSmith> | right |
| 06:28 | <MikeSmith> | anyway the web runtime is always the oddball |
| 06:28 | <MikeSmith> | see the channel /topic and all that |
| 06:29 | <domfarolino> | So moral of the story, any state-changing server endpoints that can be accessed via CORS should be written in such a way (seemingly accepting POST is sufficient) that requests to it will def be preflighted |
| 06:29 | <domfarolino> | Yeah haha trueee |
| 06:34 | <domfarolino> | Question: is it possible to programmatically get the response to a script requested with CORS (not using fetch). Like If I were to programmatically insert a script whose crossorigin attr was set, and I insert it into say the head..can I, even then, get at its response? Should be no prob from a websec standpoint, but is there a mechanism to do this? |
| 06:38 | <MikeSmith> | domfarolino: no mechanism do that as far as I know |
| 06:39 | <MikeSmith> | you’d instead need to initiate the request using fetch() or XHR rather than script element |
| 06:40 | <domfarolino> | ✔ |
| 10:14 | <zcorpan> | mkwst: https://github.com/whatwg/fetch/issues/546 - NSFW results when doing compat analysis is a bit annoying (for me); possibly worse than annoying for others. (I can cope fine with "regular" porn sites, though I didn't want to see animal porn...) Wonder if something can/should be done about this |
| 10:32 | <mkwst> | zcorpan: Sorry. I didn't actually visit all the sites, just `view-source:[site]`. I only pulled up the site when the hit wasn't in the actual body of the page. |
| 10:32 | <mkwst> | Which site should I have flagged? |
| 10:33 | <mkwst> | (Really, sorry. I didn't mean to send to you horribleness.) |
| 10:33 | <zcorpan> | mkwst: I didn't look at these results, just noted you marked some as NSFW. The animal porn was from earlier analysis I did a while back, unrelated to this. Sorry for being unclear! |
| 10:34 | <mkwst> | Oh, good. :) |
| 10:35 | <mkwst> | I was going through `javascript:` URL navigation hits on Friday, and that seemed pretty bad, which lead me to the `view-source:` method today. |
| 10:36 | <mkwst> | It works pretty well. I only had to actually visit ~8 or so sites today. |
| 10:36 | <zcorpan> | yeah I also opt for view-source: unless I want to see what's broken visually. Faster to load as well |
| 10:39 | <gsnedders> | zcorpan: also, FWIW, there are places like the UK where the legal status of visiting such sites is dubious (i.e., visiting them *is* illegal, though unknowingly clicking on a link to them is legal, but it means that one probably doesn't want to spend time clicking around) |
| 10:43 | <zcorpan> | I added a bullet point to https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit# |
| 10:49 | <nox> | Why is drafts.csswg.org often damn slow? |
| 10:52 | <MikeSmith> | nox: if it’s slower than normal the best person to give a heads-up to is plinss |
| 10:52 | <nox> | MikeSmith: Meh, fast Internet probably spolied me. |
| 10:52 | <nox> | spoiled* |
| 10:53 | <MikeSmith> | OK |
| 13:43 | <yoav_> | annevk: Getting back to https://github.com/whatwg/fetch/pull/442#discussion_r103624566 (finally) |
| 13:43 | <yoav> | should the potential destination be linked to a specific request, or should it be a detached concept that translates to destination? |
| 13:45 | <annevk> | yoav: I would say detached |
| 13:45 | <annevk> | yoav: just like you can normalize a method without a request |
| 13:45 | <yoav> | OK, makes sense |
| 14:28 | <zcorpan> | Anyone want to review https://github.com/w3c/fxtf-drafts/pull/169 ? (non-normative, should be pretty quick, but blocks me sending an email proposing a WD) |
| 14:32 | <zcorpan> | Domenic? ^ |
| 14:32 | <Domenic> | sure |
| 14:32 | <zcorpan> | ❤️ |
| 14:36 | <Domenic> | Hmm, it seems a bit unfortunate it's new DOMPoint(x, y, z, w) but new DOMMatrix([m11, ...]), i.e. you need extra []s for DOMMatrix |
| 14:36 | <yoav> | annevk: one more Q. Would you like the elimination of empty potential-destination happen at the caller, or as part of the translation into a destination? |
| 14:36 | <yoav> | If it's the latter, I'd love some guidance as to how to define it |
| 14:37 | <zcorpan> | Domenic: yeah... |
| 14:38 | <zcorpan> | Domenic: could maybe change it, but extra churn, and another incompatible change from what gecko has shipped for a few years |
| 14:39 | <Domenic> | Yeah, probably not worth it. |
| 14:44 | <zcorpan> | Domenic: I guess remove "Changed <code>fromString()</code> static method to overloaded constructor." since that didn't exist in the previous WD |
| 14:46 | <Domenic> | Oh, yeah, I'm not up to date on my WDs :P |
| 14:47 | <zcorpan> | Domenic: ok PTAL |
| 14:48 | <zcorpan> | Domenic: you mean you didn't read the previous WD cover-to-cover, multiple times, then backwards at least once?! |
| 14:48 | <Domenic> | zcorpan: gotta go afk for ~30 mins, sorry! But feel free to merge. |
| 14:48 | <yoav> | annevk: nm. I think I figured it out |
| 14:48 | <zcorpan> | ok. thx |
| 15:29 | <annevk> | yoav: the caller would invoke this before creating a request, I'd think |
| 15:30 | <annevk> | yoav: until we have some kind of lowercase-request creator algorithm |
| 15:34 | <annevk> | Domenic: https://tools.ietf.org/html/rfc8174 |
| 15:34 | <annevk> | Domenic: guess we need to fork 2119 |
| 15:34 | <Domenic> | Oh boy |
| 15:35 | <Domenic> | "2. Clarifying Capitalization of Key Words" "NEW" text seems rather IETF-specific and verbose. |
| 15:35 | <Domenic> | Oh I see the portion other specs are supposed to use is smaller |
| 15:36 | <Domenic> | I guess we should indirect everything through Infra and then Infra can say something about ignoring RFC 8174. |
| 15:36 | <Domenic> | Maybe we can move "willful violation" to Infra too hrm |
| 15:42 | <jugglinmike> | Domenic: when should I expect this definition to be available through Bikeshed? |
| 15:43 | <Domenic> | jugglinmike: usually less than 24 hours; my understanding is the ingestion process happens at some set time every day. (TabAtkins may know exactly when.) After it is then you need to do bikeshed update, or use the web service. |
| 15:43 | <jugglinmike> | got it. Thanks! |
| 15:51 | <annevk> | Domenic: sgtm |
| 15:52 | <Domenic> | Will file an issue so I don't forget, maybe a PR later |