Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #20047 > unrolled thread

Parallel Download Abstraction

Back to article view | Back to comp.lang.javascript

Contents

  Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-05-29 17:09 -0700
    Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-30 03:01 +0200
      Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-05-29 19:17 -0700
        Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-30 05:13 +0200
          Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-05-30 17:56 -0700
            Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-31 14:59 +0200
              Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-01 03:18 -0700
                Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-01 15:10 +0200
                  Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-01 18:21 -0700
                    Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-03 14:50 +0200
                      Re: Parallel Download Abstraction Stefan Weiss <krewecherl@gmail.com> - 2013-06-04 02:20 +0200
                        Re: Parallel Download Abstraction Scott Sauyet <scott.sauyet@gmail.com> - 2013-06-03 18:04 -0700
                      Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-03 20:01 -0700
                Re: Parallel Download Abstraction Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-01 15:15 +0200
                  Re: Parallel Download Abstraction "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-06-01 18:05 -0700

#20047 — Parallel Download Abstraction

Will the following perform the same parallel download semantics if it
is abstracted into a different file?

...
        <script>
            document.write("<script src='script1'></script>")
            document.write("<script src='script2'></script>")
        </script>
    <body>
</html>

becoming:

        <script src='writeTwo'></script>
    </body>
</html>

[toc] | [next] | [standalone]

#20048

Michael Haufe (TNO) wrote:

> Will the following perform the same parallel download semantics if it
> is abstracted into a different file?
> 
> ...
>         <script>
>             document.write("<script src='script1'></script>")
>             document.write("<script src='script2'></script>")
>         </script>
>     <body>
> </html>
> 
> becoming:
> 
>         <script src='writeTwo'></script>
>     </body>
> </html>

Yes, it will also _not_ achieve “parallel download”.

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#20049

Did you say "also", because I forgot to escape the </script> tag for
this post, or is there another reason as well?

On May 29, 8:01 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Michael Haufe (TNO) wrote:
> > Will the following perform the same parallel download semantics if it
> > is abstracted into a different file?
>
> > ...
> >         <script>
> >             document.write("<script src='script1'></script>")
> >             document.write("<script src='script2'></script>")
> >         </script>
> >     <body>
> > </html>
>
> > becoming:
>
> >         <script src='writeTwo'></script>
> >     </body>
> > </html>
>
> Yes, it will also _not_ achieve “parallel download”.

[toc] | [prev] | [next] | [standalone]

#20052

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Will the following perform the same parallel download semantics if it
>> > is abstracted into a different file?
>> > 
>> > ...
>> > <script>
>> > document.write("<script src='script1'></script>")
>> > document.write("<script src='script2'></script>")
>> > </script>
>> > <body>
>> > </html>
>> > 
>> > becoming:
>> >
>> > <script src='writeTwo'></script>
>> > </body>
>> > </html>
>>
>> Yes, it will also _not_ achieve “parallel download”.
> 
> Did you say "also", because I forgot to escape the </script> tag for
> this post, or is there another reason as well?

Please do not top-post.

I said “also” because it is unlikely that either of the two approaches will 
result in “parallel download”.  Scripts, when included this way, are always 
processed sequentially, and AFAIK are also downloaded sequentially:

<https://developers.google.com/speed/articles/include-scripts-properly>

Usually it is a bad idea to use document.write() to include content, 
particularly script content, nowadays:

<https://developers.google.com/speed/docs/best-practices/rtt?hl=en#AvoidDocumentWrite>

A possibility for parallel download is asynchronous XHR using two different 
XHR instances, and inserting “script” elements with the resource's content 
each upon completion, as I do synchronously in jsx.importFrom():

<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=/trunk/object.js>

(Changing that to asynchronous loading is accomplished by simply passing 
“true” instead of “false” for the third argument.  I shall work on that;
to date it did not occur to me that it could be useful to load scripts 
asynchronously.)


I did not comment on the missing escaping of </script> because from your 
<script> tag I assumed that you would use HTML5, and I assumed that because 
it is not SGML-based, escaping of “</” was no longer necessary there.  
However, indeed it is still necessary to avoid </script> being parsed as the 
end-tag of the “script” element:

<http://www.w3.org/TR/2012/CR-html5-20121217/scripting-1.html#restrictions-for-contents-of-script-elements>

That said, for backwards-compatibility it is certainly wise to escape “</” 
*always* within a “script” element.  Likewise for using 
“type="text/javascript"” on “script” elements and “type="text/css"” on 
“style” elements.

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#20060

On May 29, 10:13 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Please do not top-post.

ACK

> I said “also” because it is unlikely that either of the two approaches will
> result in “parallel download”.  Scripts, when included this way, are always
> processed sequentially, and AFAIK are also downloaded sequentially:
>
> <https://developers.google.com/speed/articles/include-scripts-properly>

Actually, the scripts are downloaded in parallel but executed in the
order they're written to the page. This works in legacy IE as well,
though from testing it looks like it is irrelevant in modern browsers.

> Usually it is a bad idea to use document.write() to include content,
> particularly script content, nowadays:
>
> <https://developers.google.com/speed/docs/best-practices/rtt?hl=en#Avo...>

I agree if I was only targeting modern browsers which can actually
perform the mentioned, static, predictive downloading.

> A possibility for parallel download is asynchronous XHR using two different
> XHR instances, and inserting “script” elements with the resource's content
> each upon completion, as I do synchronously in jsx.importFrom():
>
> <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=/trunk/...>
>
> (Changing that to asynchronous loading is accomplished by simply passing
> “true” instead of “false” for the third argument.  I shall work on that;
> to date it did not occur to me that it could be useful to load scripts
> asynchronously.)

Cross-Domain issues not-withstanding of course.

> I did not comment on the missing escaping of </script> because from your
> <script> tag I assumed that you would use HTML5, and I assumed that because
> it is not SGML-based, escaping of “</” was no longer necessary there.
> However, indeed it is still necessary to avoid </script> being parsed as the
> end-tag of the “script” element:
>
> <http://www.w3.org/TR/2012/CR-html5-20121217/scripting-1.html#restrict...>
>
> That said, for backwards-compatibility it is certainly wise to escape “</”
> *always* within a “script” element.

Your assumption gave me too much credit in this case. It was a typo; I
was also unaware that this escaping was no longer necessary.

> Likewise for using
> “type="text/javascript"” on “script” elements and “type="text/css"” on
> “style” elements.

HTML 5 states that this is optional for <script> tags, and while HTML
4 requires it, the de-facto default has been "text/javascript". While
I've never come across the issue, nor expect to, I can see the
argument that it is possible for some server misconfiguration to set
an innapropriate "Content-Script-Type" header.

For styles, the default in both standards is "text/css"

[toc] | [prev] | [next] | [standalone]

#20063

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> I said “also” because it is unlikely that either of the two approaches
>> will result in “parallel download”.  Scripts, when included this way, are
>> always processed sequentially, and AFAIK are also downloaded
>> sequentially:
>>
>> <https://developers.google.com/speed/articles/include-scripts-properly>
> 
> Actually, the scripts are downloaded in parallel but executed in the
> order they're written to the page. This works in legacy IE as well,

How do you know that?  Both the text and the video there suggest that script 
resources are always downloaded sequentially, to the point that they block 
parsing of subsequent markup.

> though from testing it looks like it is irrelevant in modern browsers.

Please post the public URI of your pertinent testcase(s), list the UAs and 
describe the methods that produced your results.
 
>> Usually it is a bad idea to use document.write() to include content,
>> particularly script content, nowadays:
>>
>> <https://developers.google.com/speed/docs/best-practices/rtt?hl=en#Avo...>
> 
> I agree if I was only targeting modern browsers which can actually
> perform the mentioned, static, predictive downloading.

The MSDN Library library suggests that Element::appendChild() has been 
supported since MSHTML 5.x (1999/2000); caniuse.com and the local DOM 
Support Matrix provide no pertinent information yet.

Previously there were .insertAdjacentHTML() and .innerHTML, although I am 
not sure if the earlier UAs would load scripts included this way (and I 
cannot test it).

>> A possibility for parallel download is asynchronous XHR using two
>> different XHR instances, and inserting “script” elements with the
>> resource's content each upon completion, as I do synchronously in
>> jsx.importFrom(): 
>>
>> [URI]
>>
>> (Changing that to asynchronous loading is accomplished by simply passing
>> “true” instead of “false” for the third argument.  I shall work on that;
>> to date it did not occur to me that it could be useful to load scripts
>> asynchronously.)
> 
> Cross-Domain issues not-withstanding of course.

Good point.  If such an issue would occur, should the method automatically 
fall back to “script” element insertion to which the SOP does not apply by 
default?
 
>> I did not comment on the missing escaping of </script> because from your
>> <script> tag I assumed that you would use HTML5, and I assumed that
>> because it is not SGML-based, escaping of “</” was no longer necessary
>> there. However, indeed it is still necessary to avoid </script> being
>> parsed as the end-tag of the “script” element:
>>
>> [URI]<http://www.w3.org/TR/2012/CR-html5-20121217/scripting-1.html#restrict...>
>>
>> That said, for backwards-compatibility it is certainly wise to escape
>> “</” *always* within a “script” element.
> 
> Your assumption gave me too much credit in this case. It was a typo; I
> was also unaware that this escaping was no longer necessary.

Escaping “</” *is* still necessary in HTML5, but only for pseudo-end-tags of 
pseudo-“script” elements within proper “script” elements, and probably (I 
have not checked the grammar) for pseudo-end-tags of pseudo-“style” elements 
in proper “style” elements.  Unless I have not considered another element 
type.
 
>> Likewise for using “type="text/javascript"” on “script” elements and
>> “type="text/css"” on “style” elements.
> 
> HTML 5 states that this is optional for <script> tags, and while HTML
> 4 requires it, the de-facto default has been "text/javascript".

Possible, unless you used a different scripting language (like VBScript) 
before said SCRIPT element.  I am also not sure about MSHTMLs language 
labels in “href” and event-handler attribute values.

> While I've never come across the issue, nor expect to, I can see the
> argument that it is possible for some server misconfiguration to set
> an innapropriate "Content-Script-Type" header.
> 
> For styles, the default in both standards is "text/css"

The “type” attribute is #REQUIRED on the SCRIPT *and* STYLE element in HTML 
4.  There is no default value:

<http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#edef-SCRIPT>
<http://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html#edef-STYLE>

The pertinent META elements and corresponding HTTP header fields are 
supposed to apply only to event-handler attribute values and the “style” 
*attribute* (ibid.; see below and above that, respectively).  I am not aware 
of a UA that observes them for SCRIPT and STYLE elements, respectively.

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#20102

On May 31, 7:59 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> I said “also” because it is unlikely that either of the two approaches
> >> will result in “parallel download”.  Scripts, when included this way, are
> >> always processed sequentially, and AFAIK are also downloaded
> >> sequentially:
>
> >> <https://developers.google.com/speed/articles/include-scripts-properly>
>
> > Actually, the scripts are downloaded in parallel but executed in the
> > order they're written to the page. This works in legacy IE as well,
>
> How do you know that?  Both the text and the video there suggest that script
> resources are always downloaded sequentially, to the point that they block
> parsing of subsequent markup.
>
> > though from testing it looks like it is irrelevant in modern browsers.
>
> Please post the public URI of your pertinent testcase(s), list the UAs and
> describe the methods that produced your results.


<https://thenewobjective.com/tests/parallel-downloads/>

results thus far:

Browser    normal    document.write
IE6        parallel  parallel
IE9        parallel  parallel
Fx 3.6.28  parallel  staircase
Fx 4.0.1   parallel  parallel
Fx 22      parallel  parallel
Op 10.63   staircase parallel
Op 12      parallel  staircase
Saf 5.1.7  parallel  parallel
Ch 27      parallel  parallel

Oracle VirtualBox + Win XP used for IE6, Fx < 22, Op < 12
Windows Vista for the rest
Debug Bar addon for IE6
Firebug on legacy Fx, native tool on Fx 22
Dragonfly for all Opera versions
native tool for Chrome 27

The OS image downloads are quite time consuming, so I haven't looked
at IE7 or IE8 yet.

> The MSDN Library library suggests that Element::appendChild() has been
> supported since MSHTML 5.x (1999/2000); caniuse.com and the local DOM
> Support Matrix provide no pertinent information yet.
>
> Previously there were .insertAdjacentHTML() and .innerHTML, although I am
> not sure if the earlier UAs would load scripts included this way (and I
> cannot test it).

If memory serves correct, I think Firefox restricted this behavior
around
version 3 for XSS security (This may only be for html from a 3rd party
though). It couldn't hurt to test.

> >> A possibility for parallel download is asynchronous XHR using two
> >> different XHR instances, and inserting “script” elements with the
> >> resource's content each upon completion, as I do synchronously in
> >> jsx.importFrom():
>
> >> [URI]
>
> >> (Changing that to asynchronous loading is accomplished by simply passing
> >> “true” instead of “false” for the third argument.  I shall work on that;
> >> to date it did not occur to me that it could be useful to load scripts
> >> asynchronously.)
>
> > Cross-Domain issues not-withstanding of course.
>
> Good point.  If such an issue would occur, should the method automatically
> fall back to “script” element insertion to which the SOP does not apply by
> default?

The problem here though is that I am under the impression that legacy
IE
executes external scripts (outside of document.write) in the order
they
are loaded and not when attached to the document like Fx and others.
Ref: <https://blogs.msdn.com/b/kristoffer/archive/2006/12/22/loading-
javascript-files-in-parallel.aspx?Redirected=true>

Of course you could argue that would be the script authors' fault for
relying on
ordered dependencies and assuming properties of the utilizing
environment.

I would suggest making it explicit which approach is used as the
semantics differ.

> > For styles, the default in both standards is "text/css"
>
> The “type” attribute is #REQUIRED on the SCRIPT *and* STYLE element in HTML
> 4.  There is no default value:
>
> <http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#...>
> <http://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html#ed...>

I'm referring to the following:
<http://www.w3.org/TR/html401/present/styles.html#h-14.2.1>

<quote>
User agents should determine the default style sheet language for a
document according to the following steps (highest to lowest
priority):

1. If any META declarations specify the "Content-Style-Type", the last
one in the character stream determines the default style sheet
language.
2. Otherwise, if any HTTP headers specify the "Content-Style-Type",
the last one in the character stream determines the default style
sheet language.
3. Otherwise, the default style sheet language is "text/css".
</quote>

[toc] | [prev] | [next] | [standalone]

#20103

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> I said “also” because it is unlikely that either of the two approaches
>> >> will result in “parallel download”.  Scripts, when included this way,
>> >> are always processed sequentially, and AFAIK are also downloaded
>> >> sequentially:
>> >>
>> >> <https://developers.google.com/speed/articles/include-scripts->> >> properly>
>> >>
>> > Actually, the scripts are downloaded in parallel but executed in the
>> > order they're written to the page. This works in legacy IE as well,
>>
>> How do you know that?  Both the text and the video there suggest that
>> script resources are always downloaded sequentially, to the point that
>> they block parsing of subsequent markup.
>>
>> > though from testing it looks like it is irrelevant in modern browsers.
>>
>> Please post the public URI of your pertinent testcase(s), list the UAs
>> and describe the methods that produced your results.
> 
> <https://thenewobjective.com/tests/parallel-downloads/>
> 
> results thus far:
> 
> Browser    normal    document.write
> […]
> Ch 27      parallel  parallel
> 
> […]

Thank you.  Using your testcases and the Chrome Developer Tools' “Network” 
tab, in 10 out of 10 cases I can confirm parallel (“P”) uncached download 
for the document.write() approach in

"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/27.0.1453.93 Safari/537.36"

I cannot confirm your observations for the “normal” way (static script 
elements [1]) there.  In most cases scripts are downloaded uncached 
sequentially (“S”) instead, as demonstrated in the video by Tony Gentilcore 
(Co-Creator of the Google PageSpeed Tools) in what looks like IE 9 (referred 
above).

Uncached run #   |  1  2  3  4  5  6  7  8  9 10
-----------------+------------------------------
normal/inline    |  P  S  S  S  P  S  S  S  S  S
document.write() |  P  P  P  P  P  P  P  P  P  P


[1]
<https://thenewobjective.com/tests/parallel-downloads/inline-script.html>
 
>> The MSDN Library library suggests that Element::appendChild() has been
>> supported since MSHTML 5.x (1999/2000); caniuse.com and the local DOM
>> Support Matrix provide no pertinent information yet.
>>
>> Previously there were .insertAdjacentHTML() and .innerHTML, although I am
>> not sure if the earlier UAs would load scripts included this way (and I
>> cannot test it).
> 
> If memory serves correct, I think Firefox restricted this behavior
> around version 3 for XSS security (This may only be for html from a 3rd
> party though). It couldn't hurt to test.

I have just tested it in

"Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 
Iceweasel/18.0.1"

in the Firebug 1.11.4 console on <http://en.wikipedia.org/wiki/Castling>
(which I happened to have visited last there) with

  /* Kids, don't try this at home! */
  var script = document.createElement("script");
  script.src = "http://PointedEars.de/scripts/object.js";
  document.body.appendChild(script);

It works (jsx.object is available then).  If you think about it, you *had* 
to be mistaken about a general restriction for cross-origin scripts: if you 
had been correct, for example the Google Maps API would have stopped working 
except on the Google Maps web site from Firefox 3.0 on.  And a lot of web 
trackers, including Google Analytics, would suddenly have failed.

You will find inserting “script” elements documented as a way to work around 
the SOP in MDN –

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript>

– and elsewhere.  XSS is a different issue:

<https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Content_Security_Policy>

>> Good point.  If such [an cross-origin issue with XHR] would occur, should
>> the method automatically fall back to “script” element insertion
>> to which the SOP does not apply by default?
> 
> The problem here though is that I am under the impression that legacy
> IE executes external scripts (outside of document.write) in the order
> they are loaded and not when attached to the document like Fx and others.
> Ref: <https://blogs.msdn.com/b/kristoffer/archive/2006/12/22/loading-> javascript-files-in-parallel.aspx?Redirected=true>

Interesting.  I shall test that assertion then.
 
> Of course you could argue that would be the script authors' fault for
> relying on ordered dependencies and assuming properties of the utilizing
> environment.
> 
> I would suggest making it explicit which approach is used as the
> semantics differ.

ACK.
 
>> > For styles, the default in both standards is "text/css"
>>
>> The “type” attribute is #REQUIRED on the SCRIPT *and* STYLE element in
>> HTML 4.  There is no default value:
>>
>> <http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#...>
>> <http://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html#ed...>
> 
> I'm referring to the following:
> <http://www.w3.org/TR/html401/present/styles.html#h-14.2.1>
> 
> <quote>
> User agents should determine the default style sheet language for a
> document according to the following steps (highest to lowest
> priority):
> 
> 1. If any META declarations specify the "Content-Style-Type", the last
> one in the character stream determines the default style sheet
> language.
> 2. Otherwise, if any HTTP headers specify the "Content-Style-Type",
> the last one in the character stream determines the default style
> sheet language.
> 3. Otherwise, the default style sheet language is "text/css".
> </quote>

And AISB, this is followed by:

| Documents that include elements that set the style attribute but which
                                                     ^^^^^^^^^
| don't define a default style sheet language are incorrect. Authoring tools
| should generate default style sheet language information (typically a META
| declaration) so that user agents do not have to rely on a default of
| "text/css".

and later

| <!ELEMENT STYLE - - %StyleSheet        -- style info -->
| <!ATTLIST STYLE
|   %i18n;                               -- lang, dir, for use with title --
|   type        %ContentType;  #REQUIRED -- content type of style language
                               ^^^^^^^^^
| --

If there were a default value of "text/css" for the “type” attribute of the 
STYLE element, the attribute declaration would look as follows:

<!ATTLIST STYLE
  -- […] --
  type        %ContentType; "text/css" -- content type of style language --
  -- […] --

See for example:

,-<http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#edef-FORM>
| 
| <!ATTLIST FORM
|   %attrs;                              -- %coreattrs, %i18n, %events --
|   action      %URI;          #REQUIRED -- server-side form handler --
|   method      (GET|POST)     GET       -- HTTP method used to submit the
| form--
|   enctype     %ContentType;  "application/x-www-form-urlencoded"
| […]

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#20114

On Jun 1, 8:10 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Michael Haufe (TNO) wrote:

[...]

> Thank you.  Using your testcases and the Chrome Developer Tools' “Network”
> tab, in 10 out of 10 cases I can confirm parallel (“P”) uncached download
> for the document.write() approach in
>
> "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/27.0.1453.93 Safari/537.36"
>
> I cannot confirm your observations for the “normal” way (static script
> elements [1]) there.  In most cases scripts are downloaded uncached
> sequentially (“S”) instead, as demonstrated in the video by Tony Gentilcore
> (Co-Creator of the Google PageSpeed Tools) in what looks like IE 9 (referred
> above).
>
> Uncached run #   |  1  2  3  4  5  6  7  8  9 10
> -----------------+------------------------------
> normal/inline    |  P  S  S  S  P  S  S  S  S  S
> document.write() |  P  P  P  P  P  P  P  P  P  P
>
> [1]
> <https://thenewobjective.com/tests/parallel-downloads/inline-script.html>

I reinstalled the VM and revisited the tests. In case of formatting
issues, the below table is available here: <https://
thenewobjective.com/tests/parallel-downloads/browser-results.txt>

Static:  <script>
Dynamic: document.write
S: Sequential download
P: Parallel download

                            Run #
Browser  Type     1  2  3  4  5  6  7  8  9  10
------------------------------------------------
IE6      Static   S  S  S  S  S  S  S  S  S  S
         Dynamic  P  P  P  P  P  P  P  P  P  P
* debugbar add-on
------------------------------------------------
IE7      Static   S  S  S  S  S  S  S  S  S  S
         Dynamic  P  P  P  P  P  P  P  P  P  P
* debugbar add-on
------------------------------------------------
IE8      Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  P  P  P  P  P  P  P  P  P  P
* HTTP Analyzer tool used
* debugbar buggy in this version
* native tools available, but not a network
  profiler
------------------------------------------------
IE9      Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  P  P  P  P  P  P  P  P  P  P
------------------------------------------------
Op 9.64  Static   S  S  S  S  S  S  S  S  S  S
         Dynamic  P  P  P  P  P  P  P  P  P  P
* HTTP Analyzer tool used (SSL had to be disabled
  on domain for this tool to work)
------------------------------------------------
Op 10.63 Static   S  S  S  S  S  S  S  S  S  S
         Dynamic  P  P  P  P  P  P  P  P  P  P
------------------------------------------------
Op 12.15 Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  S  S  S  S  S  S  S  S  S  S
------------------------------------------------
Sa 5.1.7 Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  P  P  P  P  P  P  P  P  P  P
------------------------------------------------
Fx 3.6.28 Static  P  P  P  P  P  P  P  P  P  P
          Dynamic S  S  S  S  S  S  S  S  S  S
------------------------------------------------
Fx 4.0.1 Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  P  P  P  P  P  P  P  P  P  P
------------------------------------------------
Fx 22    Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  P  P  P  P  P  P  P  P  P  P
------------------------------------------------
Ch 27    Static   P  P  P  P  P  P  P  P  P  P
         Dynamic  P  P  P  P  P  P  P  P  P  P

If you wish to duplicate my results using the HTTPAnalyzer/debugbar
tools, use the http protocol of my domain or you'll get an empty log.

I also renamed inline-script.html to static-script.html

> >> The MSDN Library library suggests that Element::appendChild() has been
> >> supported since MSHTML 5.x (1999/2000); caniuse.com and the local DOM
> >> Support Matrix provide no pertinent information yet.
>
> >> Previously there were .insertAdjacentHTML() and .innerHTML, although I am
> >> not sure if the earlier UAs would load scripts included this way (and I
> >> cannot test it).
>
> > If memory serves correct, I think Firefox restricted this behavior
> > around version 3 for XSS security (This may only be for html from a 3rd
> > party though). It couldn't hurt to test.
>
> I have just tested it in
>
> "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
> Iceweasel/18.0.1"
>
> in the Firebug 1.11.4 console on <http://en.wikipedia.org/wiki/Castling>
> (which I happened to have visited last there) with
>
>   /* Kids, don't try this at home! */
>   var script = document.createElement("script");
>   script.src = "http://PointedEars.de/scripts/object.js";
>   document.body.appendChild(script);
>
> It works (jsx.object is available then).  If you think about it, you *had*
> to be mistaken about a general restriction for cross-origin scripts: if you
> had been correct, for example the Google Maps API would have stopped working
> except on the Google Maps web site from Firefox 3.0 on.  And a lot of web
> trackers, including Google Analytics, would suddenly have failed.
>
> You will find inserting “script” elements documented as a way to work around
> the SOP in MDN –
>
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_p...>
>
> – and elsewhere.  XSS is a different issue:
>
> <https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Con...>

I found what I was thinking of:

<https://developer.mozilla.org/en-US/docs/Web/API/
element.innerHTML#Security_considerations>

innerHTML w/ <script> doesn't work.

> > I'm referring to the following:
> > <http://www.w3.org/TR/html401/present/styles.html#h-14.2.1>
>
> > <quote>
> > User agents should determine the default style sheet language for a
> > document according to the following steps (highest to lowest
> > priority):
>
> > 1. If any META declarations specify the "Content-Style-Type", the last
> > one in the character stream determines the default style sheet
> > language.
> > 2. Otherwise, if any HTTP headers specify the "Content-Style-Type",
> > the last one in the character stream determines the default style
> > sheet language.
> > 3. Otherwise, the default style sheet language is "text/css".
> > </quote>
>
> And AISB, this is followed by:
>
> | Documents that include elements that set the style attribute but which
>                                                      ^^^^^^^^^
> | don't define a default style sheet language are incorrect. Authoring tools
> | should generate default style sheet language information (typically a META
> | declaration) so that user agents do not have to rely on a default of
> | "text/css".
>
> and later
>
> | <!ELEMENT STYLE - - %StyleSheet        -- style info -->
> | <!ATTLIST STYLE
> |   %i18n;                               -- lang, dir, for use with title --
> |   type        %ContentType;  #REQUIRED -- content type of style language

Yes, I saw this but ignored it as it is not a practice of mine to have
an inline style. So it is a relevant point, but did not apply to my
current practices. Though EIBTI I suppose...

[toc] | [prev] | [next] | [standalone]

#20124

Michael Haufe (TNO) wrote:

> On Jun 1, 8:10 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Michael Haufe (TNO) wrote:
> 
> [...]
> 
>> Thank you.  Using your testcases and the Chrome Developer Tools'
>> “Network” tab, in 10 out of 10 cases I can confirm parallel (“P”)
>> uncached download for the document.write() approach in
>>
>> "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/27.0.1453.93 Safari/537.36"
>>
>> I cannot confirm your observations for the “normal” way (static script
>> elements [1]) there.  In most cases scripts are downloaded uncached
>> sequentially (“S”) instead, as demonstrated in the video by Tony
>> Gentilcore (Co-Creator of the Google PageSpeed Tools) in what looks like
>> IE 9 (referred above).
>>
>> Uncached run #   |  1  2  3  4  5  6  7  8  9 10
>> -----------------+------------------------------
>> normal/inline    |  P  S  S  S  P  S  S  S  S  S
>> document.write() |  P  P  P  P  P  P  P  P  P  P
>>
>> [1]
>> <https://thenewobjective.com/tests/parallel-downloads/inline-script.html>
> 
> I reinstalled the VM and revisited the tests. In case of formatting
> issues, the below table is available here: <https://
> thenewobjective.com/tests/parallel-downloads/browser-results.txt>
> 
> Static:  <script>
> Dynamic: document.write
> S: Sequential download
> P: Parallel download
> 
>                             Run #
> Browser  Type     1  2  3  4  5  6  7  8  9  10
> […]
> ------------------------------------------------
> Ch 27    Static   P  P  P  P  P  P  P  P  P  P
>          Dynamic  P  P  P  P  P  P  P  P  P  P
> 
> If you wish to duplicate my results using the HTTPAnalyzer/debugbar
> tools, use the http protocol of my domain or you'll get an empty log.
> 
> I also renamed inline-script.html to static-script.html

I find it strange how we can obtain so different results.  What are the 
values of navigator.userAgent with you, and which add-ons have you installed 
and enabled?  Rest assured I tested diligently, where “uncached” means 
holding down the Reload button and selecting “Empty cache and Hard Reload”.

I have the following Chrome extensions installed and enabled in _Chromium_ 
27 (see above):

- AdBlock 2.5.63
- Awesome Screenshot: Capture & Annotate 3.4.4
- colorPicker 0.9 0.9.90
- Docs PDF/PowerPoint Viewer (by Google) 3.10
- FlashBlock 1.2.11.10
- Google Chrome to Phone Extension 2.3.1
- Google Translate 1.2.4
- Link Checker 1.3.
- Novell Moonlight 3.99.0.3
- Smooth Gestures 0.17.7
- SmoothGestures: Plugin 0.8
- SmoothGestures: Plugin 0.9.1
- Stop Autoplay for YouTube. 0.11.5.24
- Table Capture 1.9
- Turn Off the Lights 2.2
- Web Developer 0.4.3
- WebSite Analysis Application 1.5.1
- YSlow 3.1.2
- Zattoo++ 0.6.1.3 (an extension I created that is only triggered on
  zattoo.com)

There is indication that the AdBlock extension slows things down as I could 
not reproduce sequential download when it was disabled, and got it several 
times (but not exclusively) when it was enabled.  On the other hand, it 
might be just that Chromium's HTTP connection slots were exhausted at the 
time.

See also:

<http://PointedEars.de/tmp/chromium-script-sequential.png>

In any case, it means that you cannot rely on parallel download.
 
>> >> The MSDN Library library suggests that Element::appendChild() has been
>> >> supported since MSHTML 5.x (1999/2000); caniuse.com and the local DOM
>> >> Support Matrix provide no pertinent information yet.
>>
>> >> Previously there were .insertAdjacentHTML() and .innerHTML, although I
>> >> am not sure if the earlier UAs would load scripts included this way
>> >> (and I cannot test it).
>>
>> > If memory serves correct, I think Firefox restricted this behavior
>> > around version 3 for XSS security (This may only be for html from a 3rd
>> > party though). It couldn't hurt to test.
>>
>> I have just tested it in
>>
>> "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
>> Iceweasel/18.0.1"
>>
>> in the Firebug 1.11.4 console on <http://en.wikipedia.org/wiki/Castling>
>> (which I happened to have visited last there) with
>>
>>   /* Kids, don't try this at home! */
>>   var script = document.createElement("script");
>>   script.src = "http://PointedEars.de/scripts/object.js";
>>   document.body.appendChild(script);
>>
>> It works (jsx.object is available then).  If you think about it, you
>> *had* to be mistaken about a general restriction for cross-origin
>> scripts: if you had been correct, for example the Google Maps API would
>> have stopped working
>> except on the Google Maps web site from Firefox 3.0 on.  And a lot of web
>> trackers, including Google Analytics, would suddenly have failed.
>>
>> You will find inserting “script” elements documented as a way to work
>> around the SOP in MDN –
>>
>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_p...>
>>
>> – and elsewhere.  XSS is a different issue:
>>
>> <https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Con...>
> 
> I found what I was thinking of:
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/
> element.innerHTML#Security_considerations>
> 
> innerHTML w/ <script> doesn't work.

ACK.  But it is a weak defense against XSS, and a specious argument from 
you:

- You have argued that you were using document.write() becaue you would not
  only target “modern browsers”.

- I have showed that even IE 5 would support document.body.appendChild(),
  also mentioning that there were fallbacks other than document.write()
  for even *older* versions (IE 4), among them .innerHTML.

- You have argued that Firefox 3+ would not execute scripts when included
  with .innerHTML.

But Firefox has supported document.body.appendChild() from its first 
version, and I have showed that, barring further measures, it is still 
loading scripts cross-domain when included this way.

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#20135

On 2013-06-03 14:50, Thomas 'PointedEars' Lahn wrote:
> I have the following Chrome extensions installed and enabled in _Chromium_ 
> 27 (see above):
[...]
> - Smooth Gestures 0.17.7
> - SmoothGestures: Plugin 0.8
> - SmoothGestures: Plugin 0.9.1

<ot>
Just FYI, this extension used to record every site you visit and send it
to their tracker site (IOW, spyware). When that got out, it was removed
from the Chrome Web Store, but re-instated later after the author
promised to mend his ways.
YMMV, but I wouldn't run anything by that author again. Fool me once,
shame on you, fool me twice... you can't get fooled again.
</ot>

- stefan
[ex-SmoothGestures user]

[toc] | [prev] | [next] | [standalone]

#20137

Stefan Weiss wrote:
> YMMV, but I wouldn't run anything by that author again. Fool me once,
> shame on you, fool me twice... you can't get fooled again.

Oh no, just when I thought it was safe...

  -- Scott

[toc] | [prev] | [next] | [standalone]

#20139

On Jun 3, 7:50 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Michael Haufe (TNO) wrote:

[...]

> >                             Run #
> > Browser  Type     1  2  3  4  5  6  7  8  9  10
> > […]
> > ------------------------------------------------
> > Ch 27    Static   P  P  P  P  P  P  P  P  P  P
> >          Dynamic  P  P  P  P  P  P  P  P  P  P
>
> > If you wish to duplicate my results using the HTTPAnalyzer/debugbar
> > tools, use the http protocol of my domain or you'll get an empty log.
>
> > I also renamed inline-script.html to static-script.html
>
> I find it strange how we can obtain so different results.  What are the
> values of navigator.userAgent with you, and which add-ons have you installed
> and enabled?  Rest assured I tested diligently, where “uncached” means
> holding down the Reload button and selecting “Empty cache and Hard Reload”.

I believe you. I only have plugins in Firefox, all other browsers are
default installations. My useragent for Ch 27 above: "Mozilla/5.0
(Windows NT 6.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/
27.0.1453.94 Safari/537.36"

[...]
> There is indication that the AdBlock extension slows things down as I could
> not reproduce sequential download when it was disabled, and got it several
> times (but not exclusively) when it was enabled.  On the other hand, it
> might be just that Chromium's HTTP connection slots were exhausted at the
> time.
>
> See also:
>
> <http://PointedEars.de/tmp/chromium-script-sequential.png>
>
> In any case, it means that you cannot rely on parallel download.

Though it has been successfully demonstrated that document.write can
be used to enable this behavior in some rather common downrev
browsers, and therefore dispensing with the adamant claims that exist
otherwise (Not from you of course). Once IE8+ is the least common
denominator, I think this interesting result can be sent to the
dustbin of history.


> > I found what I was thinking of:
>
> > <https://developer.mozilla.org/en-US/docs/Web/API/
> > element.innerHTML#Security_considerations>
>
> > innerHTML w/ <script> doesn't work.
>
> ACK.  But it is a weak defense against XSS, and a specious argument from
> you:
>
> - You have argued that you were using document.write() becaue you would not
>   only target “modern browsers”.
>
> - I have showed that even IE 5 would support document.body.appendChild(),
>   also mentioning that there were fallbacks other than document.write()
>   for even *older* versions (IE 4), among them .innerHTML.
>
> - You have argued that Firefox 3+ would not execute scripts when included
>   with .innerHTML.
>
> But Firefox has supported document.body.appendChild() from its first
> version, and I have showed that, barring further measures, it is still
> loading scripts cross-domain when included this way.

Consistent loading order could be an issue though, as referenced to
earlier.

[toc] | [prev] | [next] | [standalone]

#20104

Michael Haufe (TNO) wrote:

> <https://thenewobjective.com/tests/parallel-downloads/>

BTW: It is not necessary to concatenate '<' + 'script …>', or
'<' + '/script>'.  '<script …><\/script>' suffices.

And speaking of legacy browsers, the document.write() approach triggers the 
Netscape Run-Length Bug in Netscape versions before 6.0.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#20113

On Jun 1, 8:15 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Michael Haufe (TNO) wrote:
> > <https://thenewobjective.com/tests/parallel-downloads/>
>
> BTW: It is not necessary to concatenate '<' + 'script …>', or
> '<' + '/script>'.  '<script …><\/script>' suffices.

ACK. The page has been updated

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web