Intent to Deprecate And Remove: fetches for script tags with invalid type/language attributes

[Charles Harrison]

eng (and PM) emails

cshar...@chromium.org

Summary

Right now, the preload scanner will send fetches for script tags regardless of type/language, but the script loader will ignore them. The two systems should have the same semantics, and we should not be initiating fetches for scripts we will not use.

This was done in https://codereview.chromium.org/2099853002/ but was reverted due to a possibility of compat risks.

Motivation

This could save data for users who navigate to sites with a lot of custom script tags that are post-processed (like type=”text/template”). The original motivation for the change was a problem with mod_pagespeed pages double downloading scripts due to the preload scanner fetching them, and their post-processing doing a fetch after the resource is evicted from the memory cache.

Compatibility Risk

There is some use of this feature to ping servers. See crbug.com/626205 for the reason the original CL was reverted. The specific tag used as an example in the bug is:

<script type="text/template" src="https://www.google.com/ping"></script>

This will align us with Safari, but Firefox will request scripts regardless of type/language.

Alternative implementation suggestion for web developers

The use case of using invalid scripts to ping servers is adequately covered by the sendBeacon API.

Usage information from UseCounter

No UseCounter.

OWP launch tracking bug

https://crbug.com/626321

Entry on the feature dashboard

No entry due to small feature.

Requesting approval to remove too?

Yes

[Philip Jägenstedt]

The preload scanner doesn't have a spec (yet?) but at least https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script bails out before the fetch for an invalid type/language, so far so good.

Do you have some idea about the scope of the compat risk? crbug.com/626205 was filed within a week of the change being made, so that's not super encouraging. Can you check what Edge does?

As for alternatives, the sendBeacon API requires scripts to run, and it seems plausible that people are using this trick because it happens as early as possible. If the issue is fixed, is there any declarative alternative?

[Rick Byers]

On Thu, Jul 7, 2016 at 9:28 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

The preload scanner doesn't have a spec (yet?) but at least https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script bails out before the fetch for an invalid type/language, so far so good.

Yeah, this feels like a bug-fix to match the spec to me. 

Do you have some idea about the scope of the compat risk? crbug.com/626205 was filed within a week of the change being made, so that's not super encouraging. Can you check what Edge does?

I guess it's not really possible to have a good metric for this right?  I mean we can measure how often we are currently downloading scripts we should skip, but we can expect the vast majority of those cases won't break anything when we stop downloading.

As for alternatives, the sendBeacon API requires scripts to run, and it seems plausible that people are using this trick because it happens as early as possible. If the issue is fixed, is there any declarative alternative?

Yoav mentions in the bug that people often use a 1x1 transparent image for this, or just an empty script (with a legitimate script type).  Those also seem like reasonable alternatives - especially since I assume they work reliably across all browsers, relying only on standard behavior.

[Charles Harrison]

I'll try to test Edge later today when I can get my hands on a windows machine.

simonp@ mentions in crbug.com/329531 that people may be using script tags with invalid types as a replacement for <link rel=preload> which is another compat risk.

[Philip Jägenstedt]

On Thu, Jul 7, 2016 at 3:56 PM Rick Byers <rby...@chromium.org> wrote:

On Thu, Jul 7, 2016 at 9:28 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

The preload scanner doesn't have a spec (yet?) but at least https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script bails out before the fetch for an invalid type/language, so far so good.

Yeah, this feels like a bug-fix to match the spec to me. 

Do you have some idea about the scope of the compat risk? crbug.com/626205 was filed within a week of the change being made, so that's not super encouraging. Can you check what Edge does?

I guess it's not really possible to have a good metric for this right?  I mean we can measure how often we are currently downloading scripts we should skip, but we can expect the vast majority of those cases won't break anything when we stop downloading.

Right, I don't think that use counter would be very informative here.

As for alternatives, the sendBeacon API requires scripts to run, and it seems plausible that people are using this trick because it happens as early as possible. If the issue is fixed, is there any declarative alternative?

Yoav mentions in the bug that people often use a 1x1 transparent image for this, or just an empty script (with a legitimate script type).  Those also seem like reasonable alternatives - especially since I assume they work reliably across all browsers, relying only on standard behavior.

In the example given the URL was https://www.google.com/ping. That's not a real thing it seems, but if it's any resource that the developer doesn't control, then I guessed that it would result in a console error. It does for scripts, but it looks like broken images aren't reported, so maybe this works?

<img src=ping-thing width=1 height=1 style="visibility:hidden">

[Philip Jägenstedt]

I just did a quick test of Edge and it does make a request for this case:

<script type="text/template" src="ping.js"></script>

But it doesn't actually execute ping.js, so it looks like it's in the same boat as Blink and Gecko.

Is it only WebKit that has fixed this in the preload scanner, then? I can't see it in their HTMLPreloadScanner.cpp, are you sure they don't fetch in this case?

[Charles Harrison]

I tested Safari with an HTML file with:

<script type="text/template" src="/ping.js"></script>

And the test server is not getting a request. It's possible their preload scanner is not running, though. I also scanned through their HTMLPreloadScanner.cpp and couldn't find anything special.

[Simon Pieters]

On Thu, 07 Jul 2016 16:55:00 +0200, 'Charles Harrison' via blink-dev
<blin...@chromium.org> wrote:

> I tested Safari with an HTML file with:
> <script type="text/template" src="/ping.js"></script>
>
> And the test server is not getting a request. It's possible their preload
> scanner is not running, though. I also scanned through their
> HTMLPreloadScanner.cpp and couldn't find anything special.

I suppose you need a blocking script before it to trigger the preload
scanner, as in:

<script src="something.js"></script>

<script type="text/template" src="/ping.js"></script>

For this I get a fetch for ping.js according to the Network tab in
devtools in STP (WebKit 11602.1.39).

--
Simon Pieters
Opera Software

[Charles Harrison]

Ah thanks for the clarification. I've been away from a Mac to test this with.

In any case it looks like we'll be alone here if we make the change. What's the correct approach here?

[Simon Pieters]

On Thu, 07 Jul 2016 22:29:37 +0200, Charles Harrison
<cshar...@google.com> wrote:

> Ah thanks for the clarification. I've been away from a Mac to test this
> with.
>
> In any case it looks like we'll be alone here if we make the change.
> What's
> the correct approach here?

Earlier bug report about this contains some analysis

https://bugs.chromium.org/p/chromium/issues/detail?id=329531

There's also a bug for Gecko:

https://bugzilla.mozilla.org/show_bug.cgi?id=957054

Maybe we can do a new analysis in httparchive.

[Charles Harrison]

What would an analysis of httparchive tell us that a UseCounter couldn't? I guess we could actually inspect the more popular pages to see if they rely on this behavior?

[Simon Pieters]

I've run a query and posted results at

https://discuss.httparchive.org/t/usage-of-script-with-unsupported-type-or-language/782

Out of those, I see 132 instances of "sifr/prefetch"; 89 instances of
"text/psajs" (these seem to be pagespeed preload techniques). I would
expect the preloading to not actually work some of the time already since
it requires the preload scanner to see it.

Would it be possible to compare page load times for these URLs with and
without the CL, to see if there's a perf regression (or perf win; for some
of these pages the load is likely just wasted).

[Charles Harrison]

Thanks for the analysis. It's definitely possible to run this analysis using web page test. I'll see if I can fire off a job today.

I glanced at some sifr/prefetch code and it looks like it document.writes the script defer tag. In these cases the preload scanner will see it, because we preload scan all html inserted into the document.

[Charles Harrison]

Jobs fired. There are a lot of URLs in the corpus so it might take > 24h for the test to finish. This is on mobile with a simulated 3G network, with content_shell_apk builds from TOT (#404341) with and without the change.

Keep preloading bad script types: http://www.webpagetest.org/result/160708_X1_VTG/

Stop preloading bad script types: http://www.webpagetest.org/result/160708_QW_TT0/

[Charles Harrison]

Update: seems like I maybe broke WPT slightly with that test. Working it out right now with pmeenan@.

[Charles Harrison]

Okay we got the analysis working!

The results of the experiment page summaries are attached.

Here is a link to the analysis using ab_analysis.py in the WPT github repo. Spoiler:

The data is pretty noisy though.

[Philip Jägenstedt]

Hmm, so it looks like it's pretty evenly distributed around 0% change. Can the distribution be explained entirely by noise, or can you tease out something statistically significant from this?

[Charles Harrison]

There's not much significance unfortunately. Looking at % improvement, we're looking at a mean of 1% with a standard deviation of 17%. This could definitely be explained by noise. It might be helpful to see what some other metrics look like besides a speed index type one. I'll see if I can do that this week.

+pmeenan

[Patrick Meenan]

Does ab_analysis provide a way to dump the test ID's (or WPT URLs) as part of the comparison?  It would be interesting to look at a few of the waterfalls for some of the sites to make sure it is working as expected.

That said, if I understand the behavior change, it sounds like it wasn't a blocking resource and the invalid script type was downloading an extra resource (in some cases as a beacon and in some cases as a preload hint but resulting in duplicate fetches because of mismatched types).  Depending on the size of the resource being fetched I wouldn't be surprised that there's no measurable change.

[Charles Harrison]

I don't think it does currently. Might be able to add it locally though. I just used WPT search UI to look at the extreme outliers, but it would be nice to see them all.

[Charles Harrison]

I have updated the analysis in sheets to include columns for experiment / control urls.

I'll create a pull request adding this feature (+ some fixes) to webpagetest.

[dk...@google.com]

Is this intent blocked on API owner feedback?

[Charles Harrison]

I think this is blocked on just manually going through some of these URLs and seeing if anything looks fishy. I haven't had much time to look at this though. Will hopefully be able to look at some today.

Once we look at the data, input from API owners would be nice. I'd still like to deprecate, but judging from http://crbug.com/626205 it may not be as easy as we thought.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Charles Harrison]

Apologies, by "today" I mean "this week" :)

[Charles Harrison]

I'm looking through the script tags, filtered by ones which showed some significance on WPT.

The vast majority are false positives from the http archive scrape (i.e. document.writes with string appends).

A member of the pagespeed team actually filed the original bug for this, because there was some weird interaction with the preload and the memory cache. They were supportive of this. +Jeff for context.

Sifr/prefetches were the only other real case, and the performance of those is still all over the place:

What do API owners think?

[dk...@google.com]

Bump - looking for API owner feedback!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Hi,

Sorry for the delay (and for possibly misunderstanding the status of this intent in my questions below).

Am I correct that your analysis indicates a neutral/possibly positive impact on performance? That seems good, but it doesn't address compat risk right? Compat risk is the main issue the API owners might be concerned about.

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Charles Harrison]

Correct, this doesn't address compat risk.

So, I did a brief analysis of the results of the http archive analysis that Simon ran. Of the 496,827 sites in the dataset, 974 of them have invalid types according to the regex. That's ~.2%. These can be grouped into a few categories:

416: have a plus sign indicating they have correct types but just use string appending (causing the regex to fail)

132: sifr/prefetch. Presumably just an optimization

89: pagespeed optimization

32: jollywallet_mainframe?  src ="about:blank" and type=text/css for these.

58: look okay? Somehow failed the regex. A bunch of these had \x22 which is the quote unicode character.

161: Definitely bad types

So, 161 sites definitely look like they are doing the wrong thing here. That's .032% of the dataset.

[Charles Harrison]

I separated out the jollywallet cases because they were all alike, and it looks like jollywallet is potentially malware?

[Rick Byers]

That's great data - thanks.  Even 0.03% of the top sites is enough to justify some extra caution (especially if there performance benefit isn't large).

Do you see any obvious difference in behavior (or significant difference in performance) if you try opening a few of these pages (eg. sifr/prefetch and pagespeed optimization cases) with your change?  Perhaps you want to reach out to the pagespeed team to get their take on how your proposal would affect them?

[Jeff Kaufman]

The pagespeed cases will be positively affected by this change. They are sites running our defer_javascript filter, and the current behavior means JavaScript isn't deprioritized as much as it should be.

So I'm in favor of this change!

[Rick Byers]

On Fri, Aug 26, 2016 at 3:21 PM, Jeff Kaufman <jef...@google.com> wrote:

The pagespeed cases will be positively affected by this change. They are sites running our defer_javascript filter, and the current behavior means JavaScript isn't deprioritized as much as it should be.

So I'm in favor of this change!

Awesome, thank you!

Perhaps the sifr/pretetch cases are related to this / this?

For the remaining 161, when you say they're definitely bad types what do you mean?  The script loader will still ignore them, right?  So to what extent do these represent a compat risk?

[Charles Harrison]

Yeah, sifr/prefetch looks like a pure perf optimization. I will test some of these sites manually to see if I can notice anything.

For the remaining 161, it's hard to tell what might break. Here are some representative examples:

<script data-ds-pbase=\"true\" class=\"dsscript\" type=\"text\/dsscript\" src=\"\/\/s3-us-west-2.amazonaws.com\/distroscale-public\/vplayer-parallel\/20160317\/ds_vplayer_detached.min.js\">

<script type="text/vbscript" language="vbscript" src="http://www.reddoxx.com/upload/antispam-ev/flash.vbs">

<script type=\\\"text/java` 1\"\\\" src=\\\"\" +`\"h!` p# + \"\\\">

<script src=\http://static.dudamobile.com/dm_redirect.js\ type= ext/javascript\>

<script type="image/gif" src="http://cm.e.qq.com/cm.fcg?gdt_dspid=1316857239">

<script src=\"https:\/\/clousc.com\/player.php?ver=32\" type=\"mce-mce-text\/javascript\">

<script type="text/css" src="http://www.quran.gov.bd/common/css/ie7.css">

Note that there are some in the 161 that might still be valid after JS post-processing or a more robust script (better regex, encoding). It's a minority though.

[Rick Byers]

Ok, thanks.  I agree it's hard to know from inspection.  Maybe just try manually loading 10 of those 161 sites on a build with and without your change applied and compare the rendering and console messages? If there's no obvious breakage for 10 (or maybe 20) then that would suggest the risk is pretty low.

Personally that would be enough for me to be OK giving this a try (and watching for / investigating issues in dev/beta obviously - reconsidering if there's reports of non-trivial breakage).

Rick

[Charles Harrison]

Ok, let's see. Here's the first couple:

http://www.antispam-ev.de/ uses type="text/vbscript"

It 404s. 

http://www.personalbrandingblog.com/ uses unicode quotes within regular quotes

It 404s after a 301. 

https://www.ptgrey.com/ uses type="mce-mce-text/javascript" for three scripts that eventually load via XHR with different query strings.

For some reason we don't preload these regardless. Didn't look too closely though.

http://fifth-chome.com/ (NSFW) also does the unicode quote within regular quote thing. Also 404s.

http://www.imdb.com/ uses type="data-doubleclick" to download "blank_pixel" gif.

http://www.5vorflug.de/ uses type="text/css" but only in a comment that is <!--[if IE]>

http://www.codetools.ir/ uses the unicode quotes and gets a 404

Note: all the unicode quote examples get rewritten from e.g. <script type="”text/javascript”" src="”<url>”"> to <base_url>/”<url>”

I'll see about documenting a few more on Monday.

[PhistucK]

I think any type="text/vbscript" (or language="vbscript") can be safely ignored. They were only executed in Internet Explorer (10 and earlier) and used in very old pages. I really doubt (or maybe just very hopeful) they were used for optimizations or for anything that is a compatibility risk.

☆PhistucK

[Rick Byers]

So it sounds like all those 7 examples are completely safe, right?  Did you get a chance to look at any more?

Regardless, given that no more than ~1/7 of the 161 (of ~500k) top sites are seriously broken by this change, we're down to an estimation of this impacting no more than ~0.007% of pages.  This is low enough for me that I'm OK with the compat risk of giving this a shot.  It would be nice if we saw some larger perf benefits from this to offset the risk.  But given that we have no concrete evidence of any real breakage, I don't see any reason to ask for more analysis or delay you any further.  Of course if we find sites that are actually broken, then we should re-evaluate the cost/benefit trade-off.

LGTM1 to deprecate (with a console warning) for at least one milestone and then remove.

[Chris Harrelson]

LGTM2

[Philip Jägenstedt]

LGTM3

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Charles Harrison]

Apologies again for the delay. Thanks in any case for lgtms. Here are some more examples:

http://www.10006016.ir/ uses document.write to insert jquery with rel="stylesheet" and type="text/css" I see no purpose to this at all. So we save a fetch.

http://www.koebu.com/ uses text/html, but it's a js comment

http://www.bilesuparadize.lv/ uses "/text/javascript" but it's an html comment

http://www.codetools.ir/ uses unicode quotes and it 404s.

http://www.1cookinggames.com/ looks like have "text/java" in a script to document.write but do postprocessing so it gets the correct type. This looks like a common technique:

document.write(\"<script type=\\\"text/java` 1\"\\\" src=\\\"\" +`\"H!` p# + \"\\\"></` A\">\");

In any case, I will add the deprecation notice.

LGTM3

LGTM2

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

I am not sure I understand, do you depend on script.py being loaded (but not being accessible in any way)?

Looks like you are fetching it using XMLHttpRequest anyway, so it should not technically affect you.

The only downside is that your users might see a deprecation warning, which sucks for the pedantic user, but it is harmless in this specific case.

If you want to avoid the deprecation warning, you could add a different way of loading Python scripts, for example -

<script data-type="text/python" data-src="script.py"></script>

This will not show a deprecation warning and should work indefinitely (no guarantees, though!).

It could be that the deprecation warning would go away once the feature is completely removed, in which case, you will not have to do anything.

The only implication this removal will have on you might be some reduced performance -

Up until now, Chrome downloaded that script - which means that when Brython downloaded it using XMLHttpRequest, it might have already been in the cache, so it loaded very quickly. Now, the browser will start downloading it only when you download it using XMLHttpRequest and it will not be in the cache (for first time users, anyway).

In order to overcome that, you can tell your users to leverage <link rel="preload" href="script.py" /> which downloads the file with high priority even if it is not requested to be downloaded by XMLHttpRequest at that moment and keeps it in the cache for future use.

☆PhistucK

On Sat, Dec 17, 2016 at 9:41 AM, <pierre....@gmail.com> wrote:

LGTM3

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Hi,

I am the author and main developer of Brython, an implementation of Python for the browser. It uses <script type="text/python">
to embed scripts written in Python instead of Javascript.

Currently, a Python script can be loaded by <script type="text/python" src="script.py">. Someone just reported the
deprecation warning on Chrome.

Does this mean that this will no longer be possible ? If so it would be terribly bad news for the project. I think that text/python
should not be considered an invalid type attribute.

[Pierre Quentel]

Thanks for the quick reply.

Yes, the source code is fetched by an Ajax call. Someone on the Brython group suggested me to try with the latest Chrome beta version : with Version 56.0.2924.28 beta (64-bit) the deprecation warning is no longer printed and the script runs ok. So it seems that the change will have no impact for Brython, except the deprecation warning for a few weeks, which is not a problem.

[PhistucK]

And the performance implications i mentioned, yes.

Cool. :)

☆PhistucK

[Charles Harrison]

Thanks for the detailed explanation PhistucK! Just a quick note: sometimes the prefetch behavior that is being deprecated will actually worsen performance, depending on when the XHR request is sent out. Our preload scanner is not as aggressive as <link rel=preload>, so often the preload will be evicted before the XHR is sent out, resulting in double downloads. To guarantee preload behavior, use <link rel=preload>

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[sunnyk...@gmail.com]

I understand that invalid type/language would get ignored. But what about script tag with no type attribute (or a blank one).

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yoav Weiss]

On Thu, Dec 22, 2016 at 11:36 AM <sunnyk...@gmail.com> wrote:

I understand that invalid type/language would get ignored. But what about script tag with no type attribute (or a blank one).

That would still get properly fetched and executed. The change only avoids fetching of scripts that are *not* currently executing due to an invalid type/language. 

[Sunny Kumar Gupta]

Sounds good. +1

[fri...@jeka.info]

BTW, having a type attribute on <script> is bad practice in general, because the default script type is and was always javascript.

HTML spec says:

"Authors should omit the attribute, instead of redundantly giving a JavaScript MIME type." 

https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type

j.j.

[Simon Pieters]

On Sat, 17 Dec 2016 09:29:34 +0100, PhistucK <phis...@gmail.com> wrote:

> I am not sure I understand, do you depend on script.py being loaded (but
> not being accessible in any way)?
> Looks like you are fetching it using XMLHttpRequest anyway, so it should
> not technically affect you.
> The only downside is that your users might see a deprecation warning,
> which
> sucks for the pedantic user, but it is harmless in this specific case.
>
> If you want to avoid the deprecation warning, you could add a different
> way
> of loading Python scripts, for example -
> <script data-type="text/python" data-src="script.py"></script>

or <script type="text/python" data-src="script.py"></script> so it doesn't
accidentally execute the script's text content (if any) as JS. :-)

> This will not show a deprecation warning and should work indefinitely (no
> guarantees, though!).
>
> It could be that the deprecation warning would go away once the feature
> is
> completely removed, in which case, you will not have to do anything.
>
> The only implication this removal will have on you might be some reduced
> performance -

*improved* performance (see below).

> Up until now, Chrome downloaded that script - which means that when
> Brython
> downloaded it using XMLHttpRequest, it might have already been in the
> cache, so it loaded very quickly.

No, XHR will not reuse the resource (or the fetch, if it's still ongoing),
as I understand it, because XHR issues a different kind of fetch than
<script> does, it can't assume that the response is reusable. So the
<script> prefetch is just wasted.

Related reading:
https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/

> Now, the browser will start downloading
> it only when you download it using XMLHttpRequest and it will not be in
> the
> cache (for first time users, anyway).
> In order to overcome that, you can tell your users to leverage <link
> rel="preload" href="script.py" /> which downloads the file with high
> priority even if it is not requested to be downloaded by XMLHttpRequest
> at
> that moment and keeps it in the cache for future use.

Related issue: https://github.com/w3c/preload/issues/80 (might need
as="fetch" for the XHR case).

[PhistucK]

Right, thank you for the clarifications, I forgot about the XMLHttpRequest versus script fetch differences for a second.

I actually search for an as value and could not find it, I guess it is not standardized yet.

☆PhistucK

[Yoav Weiss]

On Fri, Dec 23, 2016 at 10:07 AM PhistucK <phis...@gmail.com> wrote:

Right, thank you for the clarifications, I forgot about the XMLHttpRequest versus script fetch differences for a second.

I actually search for an as value and could not find it, I guess it is not standardized yet.

The `as` values are defined as a Fetch destination. For scripts, the required `as` value is "script". For XHRs, it's currently the empty destination (so either an empty `as` or a missing one results in an XHR-like fetch).

We're currently debating if that is the right thing to do, or it'd be better if XHRs/fetch() required an explicit value.

[PhistucK]

Yes, I meant an as value for fetch/XMLHttpRequest, not the existence of the attribute itself in specifications. :)

☆PhistucK

[محمد‎]

The `as` values are defined as a Fetch destination. For scripts, the required `as` value is "script". For XHRs, it's currently the empty destination (so either an empty `as` or a missing one results in an XHR-like fetch).

فاروش