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

Groups > comp.lang.javascript > #20124

Re: Parallel Download Abstraction

Show all headers | View raw

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

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web