09:15
<domfarolino>
annevk: I'm a tad confused; should Request objects have an exposed `body` attribute, similar to Responses?
09:21
<domfarolino>
Seems like it should, no implementations do this right now however I couldn't find tests testing this (albeit did not spend very long looking)
11:04
<annevk>
domfarolino: it was added before we had a test requirement
11:05
<annevk>
domfarolino: there are also some open issues against Fetch related to that
11:05
<annevk>
domfarolino: but yeah, impl of request body streams has not yet happened, which is the main issue
11:31
<MikeSmith>
annevk: about the mechanism that other of our build scripts use for determining whether they’re being run under Travis or not:
11:32
<MikeSmith>
I see that whatwg.org/resources.whatwg.org/build/deploy.sh checks for a TRAVIS environment variable to see if it’s set to true
11:32
<MikeSmith>
but I don’t see where/how that TRAVIS variable ever gets set
11:33
<MikeSmith>
ah nm
11:33
<MikeSmith>
from https://docs.travis-ci.com/user/environment-variables/#Default-Environment-Variables I see it’s set by Travis itself
11:41
<annevk>
👍
12:28
<MikeSmith>
mkwst: is specifying data: as a source in a CSP policy still unsafe?
12:29
<MikeSmith>
or is it handled differently in Blink now at least?
12:29
<MikeSmith>
I mean as far as the thing about data: URLs running in a unique origin
12:30
<MikeSmith>
I don’t have a clear understanding if that makes data: safer or not as far as CSP goes
12:31
<MikeSmith>
*I mean as far as the thing about *scripts* from data: URLs running in a unique origin
15:38
<mkwst>
MikeSmith: Framed `data:` URLs produce a document running in an opaque origin (e.g. `<iframe src="data:text/html,whateverwhateverwhatever">`.
15:38
<mkwst>
MikeSmith: `<script src="data:text/javascript,whateverwhatever">` causes script to execute in your document's origin.
15:38
<mkwst>
The former might be safe, depending on what you care about.
15:39
<mkwst>
The latter almost certainly isn't safe.
15:56
<MikeSmith>
mkwst: OK, thanks