| 08:35 | <annevk> | TabAtkins: looking at that it seems that one potential problem here is that nothing marks errors with the @charset production |
| 08:36 | <annevk> | TabAtkins: e.g., if you have @charset hi { ... } it'll just be ignored |
| 11:34 | <MikeSmith> | incidentally, I wonder if the spec should normatively require authors to use UTF-8 |
| 11:35 | <MikeSmith> | to conform to the Encoding spec, with language similar to what the HTML spec has now |
| 11:35 | <annevk> | MikeSmith: probably should, given that HTML does |
| 11:35 | <MikeSmith> | yeah |
| 12:57 | <Emil> | Hey so |
| 12:58 | <Emil> | What's the correct way to allow wss connections to 'self'? |
| 12:59 | <Emil> | with csp |
| 13:02 | <annevk> | Emil: self doesn't work? |
| 13:03 | <annevk> | Emil: https://github.com/w3c/webappsec-csp/issues/7 |
| 13:06 | <Emil> | annevk: no, because even though the protocol starts as https it's upgraded to websocket and it must be specified as "wss" in the standard WebSocket api and since 'self' is https and not wss 'self' will block wss |
| 13:06 | <Emil> | annevk: so is there a workaround? |
| 13:07 | <Emil> | annevk: https://emil.fi/p/heatstream/ here's my page if you want to take a look |
| 13:08 | <Emil> | could be a chrome issue though |
| 13:08 | <Emil> | firefox only complains about Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively. |
| 13:09 | <Emil> | while chrome says script.js:202 Refused to connect to 'wss://emil.fi/websocket/heatstream'; because it violates the following Content Security Policy directive: "connect-src 'self' *.emil.fi". |
| 13:16 | <Emil> | annevk: so it might just be a chrome issue |
| 13:17 | <annevk> | Emil: ok, guess the workaround is listing the wss URL too |
| 13:17 | <annevk> | Emil: I think we should make this work everywhere though (and get it tested) |
| 13:19 | <Emil> | so I must do wss://emil.fi? |
| 13:20 | <Emil> | and wss://*.emil.fi? |
| 13:21 | <Emil> | also, one thing that'd be great is having access to the current host with say 'host' or so instead of having to write explicit *.domain.tld if I want to trust my own subdomains |
| 13:22 | <annevk> | Emil: I suspect that'll work |
| 13:23 | <annevk> | Emil: you can file feature requests against the repository I linked earlier |
| 13:23 | <annevk> | Emil: maybe search first if it hasn't been requested before |
| 13:23 | annevk | isn't entirely up-to-date on all things CSP |
| 13:31 | <Emil> | annevk: anycase thanks for confirming the issue, lets hope it gets fixed. I filed a bug report on crbug.com about this |
| 13:32 | <annevk> | Emil: maybe link that bug from the issue while you're at it? |
| 13:32 | <annevk> | Emil: always helpful to have spec and browser issues cross-linked |
| 13:33 | <Emil> | annevk: well I dun goofed and selected the security tag and apparently only users with securityTeam permissions can see the issue :D |
| 13:33 | <Emil> | https://bugs.chromium.org/p/chromium/issues/detail?id=815142&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= |
| 13:34 | <Emil> | annevk: https://emil.fi/d/2018-02-23_15-34-28_SOzY3Qkc.png picture of bug report |
| 13:35 | <annevk> | heh |
| 13:35 | <Emil> | oh yeah if you meant link the github issue yeah I linked that |
| 13:35 | <annevk> | I meant link from GitHub to https://bugs.chromium.org/p/chromium/issues/detail?id=815142 |
| 13:35 | <annevk> | But I guess wait a little until it's opened up first |
| 13:35 | <Emil> | yeah I'll do that (y) |
| 13:36 | <annevk> | Well, sorry, I meant link both ways, so what you did is definitely good |
| 13:38 | <Emil> | annevk: thanks for helping out |
| 13:46 | <Emil> | annevk: https://github.com/w3c/webappsec-csp/issues/297 and filed a feature request for exposing the host |
| 13:46 | <annevk> | cool |
| 15:35 | <annevk> | JakeA: if Fetch knows it's not a range request and it gets a range response (it can look passed the opaque bit since it's the spec/impl), it could just return a network error? |
| 15:36 | <annevk> | JakeA: so we annotate responses with whether they're range responses and if a service worker hands us a mismatch it's a network error |
| 15:43 | <JakeA> | annevk: You disagree :D https://github.com/whatwg/fetch/issues/144#issuecomment-323938559 |
| 15:43 | <JakeA> | That was my original plan |
| 15:44 | <annevk> | JakeA: I think that's slightly different |
| 15:44 | <annevk> | JakeA: that's saying that if <script> makes a request and a server gives a 206 it'll just work |
| 15:45 | <annevk> | JakeA: the Attack 4 AIUI is that <script> makes a normal request; then SW makes a Range request; then server gives a 206; then that's handed to <script> |
| 15:45 | <annevk> | JakeA: in that case it seems reasonable to reject |
| 15:46 | <annevk> | JakeA: maybe important even |
| 15:46 | <annevk> | JakeA: or am I still missing something? |
| 15:47 | <JakeA> | annevk: so how are you telling the difference between the two? The best I could think of was, in the second case, the response was gained by making a range request |
| 15:48 | <annevk> | JakeA: yeah, you mark the response somehow |
| 15:49 | <annevk> | JakeA: "range-requested flag" or some such |
| 15:49 | <JakeA> | annevk: That's the solution I wrote for attack 4, right? |
| 15:49 | <JakeA> | "Fetch should reject if the original request did not have a range header, but the service worker provides a response that is opaque, partial, and was requested with a range header." |
| 15:50 | <annevk> | JakeA: yeah |
| 15:50 | <JakeA> | sold |
| 15:50 | <annevk> | JakeA: I guess you're saying I should have said "agreed" instead :-p |
| 15:50 | <JakeA> | annevk: haha, I thought at first you were proposing an alternative |
| 15:52 | <annevk> | JakeA: thanks for continuing to tackle this |
| 15:53 | <JakeA> | annevk: np, about time really. I'll rebase that PR then make changes in additional commits. |
| 16:16 | <Emil> | annevk: https://bugs.chromium.org/p/chromium/issues/detail?id=815142 now its open |
| 16:16 | <Emil> | it's |
| 17:24 | <norbert> | hi all; I'm wondering why validator.w3.org says "No Referer header found!" for the link in the top-right of https://www.norbertdejonge.nl/ |
| 17:30 | <norbert> | ankh of #w3c helped me out; the link had to be https (can't send the header from https to http) |
| 17:46 | <annevk> | norbert: you can with referrer-policy, but that's a better fix |
| 17:49 | <norbert> | ok :) |
| 19:25 | <TabAtkins> | annevk: Nothing "marks errors" anywhere in CSS, invalid things are always silently dropped. (At most, DevTools might report something, but that can happen regardless of specs.) |
| 20:28 | <TabAtkins> | Is there a reasonable notion of what base URL to automatically use for URL-things created in JS? |
| 20:28 | <TabAtkins> | Like, by default. |
| 20:29 | <aklein> | TabAtkins: looks like for `new Image()` it's done like this: "Let document be the current global object's associated Document." |
| 20:30 | <TabAtkins> | That's exactly analogous to the sort of object I was asking the question about, thanks! |
| 20:30 | <aklein> | of course Image is super-old, so I could imagine someone coming up with a better way to do it :) |
| 20:31 | <aklein> | "better" |
| 20:31 | <TabAtkins> | I mean, that's probably the most reasonable way to do it anyway. |
| 20:32 | <TabAtkins> | I'm gonna put in some advice that if people want a relative URL resolved in a particular way, they should use the URL constructor and supply their own. |
| 20:52 | <annevk> | aklein: it does not get the base URL from the entry settings object or some such? |
| 20:53 | <annevk> | TabAtkins: note that you cannot rely on there being a document |
| 20:53 | <aklein> | annevk: hmm, maybe Image is a bad example since it requires a document |
| 20:54 | <aklein> | fetch is probably what you're thinking? |
| 20:54 | <TabAtkins> | I'm probably fine with just failing to absolutize if there's no document. |
| 20:55 | <annevk> | TabAtkins: pretty crappy for worklets et al? |
| 20:55 | <TabAtkins> | Ah, they have a URL, right. |
| 20:55 | <TabAtkins> | Man, all this ambient information floating around in DOM is hard for me to keep track of. ^_^ |
| 21:01 | <annevk> | Designed a long time ago |
| 21:01 | <annevk> | “Designed” I suppose |
| 21:48 | <Domenic> | TabAtkins: annevk: this is fixable! |
| 21:48 | <Domenic> | I think you just want to use the current or relevant settings object's API base URL |
| 21:48 | <Domenic> | relevant, unless in a constructor, then current |
| 21:49 | <Domenic> | That should just do the right thing and also be equivalent to the image thing |
| 21:49 | <Domenic> | (API base URL is derived from the active document for Window global objects; and is set correctly otherwise for worker/worklet/etc. global objects.) |
| 21:50 | <TabAtkins> | Nice |
| 22:16 | <MikeSmith> | TabAtkins: I notice the https://developer.mozilla.org/en-US/docs/Web/CSS/%40charset article describes @charset as an at-rule, so I’d like to edit that article to correct it |
| 22:16 | <MikeSmith> | but |
| 22:17 | <MikeSmith> | in looking through https://drafts.csswg.org/css-syntax-3/ I don’t really see a definition of what @charset is |
| 22:17 | <MikeSmith> | I see a note that says: |
| 22:17 | <MikeSmith> | > Note: Note that the syntax of an encoding declaration looks like the syntax of an at-rule named @charset, |
| 22:18 | <MikeSmith> | so maybe I could edit the article to have it refer to @charset as the CSS “encoding declaration”? |
| 22:19 | <MikeSmith> | otherwise, calling it, e.g., “the @charset byte sequence” doesn’t see so great |
| 22:20 | <MikeSmith> | maybe “@charset statement” |
| 22:20 | <MikeSmith> | anyway it would help if the spec itself had some formal definition of it, to refer to |
| 23:03 | <TabAtkins> | MikeSmith: It is an at-rule, in that it conforms to the general at-rule grammar. It's just not a valid CSS at-rule, as in it's not defined to exist. We use the term "at-rule" to refer to anything that matches the generic grammar, tho. |
| 23:04 | <TabAtkins> | Note that in CSS2, @charset *was* called an actual at-rule, even tho it was only paid attention to according to the stringent byte-sequence rules that Syntax describes. We just drop it from the stylesheet now, per spec, while before it would stick around and do nothing. |
| 23:04 | <MikeSmith> | ah OK |
| 23:04 | <MikeSmith> | thanks for the clarification |
