W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > December 2011

<script> 從 DOM 移除的行為(Fwd: [whatwg] Behavior when <script> is removed from DOM)

From: Kang-Hao (Kenny) Lu <kennyluck@w3.org>
Date: Fri, 23 Dec 2011 04:44:16 +0800
Message-ID: <4EF396A0.5020003@w3.org>
To: W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>
whatwg.org /2011-December/thread.html#34031


* 把 <script> 加到 DOM 裡再執行前移除的兼容行為[1]
* 為什麼會前端會想要移除 <script> → 主要是為了取消 JSONP 讀入
* 如果 XHR 支援跨來源 JSONP 就可以用 XHR 的各種功能取消 JSONP 了

因此 Mozilla 開發者 Jonas Sicking 有了一個 xhr.responseType = "jsonp";
的提案 — 如果回傳的內容可以以 JSONP 解析,就無視跨來源策略,其中最大的好
處就是不需要在全局物件上註冊函數而 xhr.response 會直接給出解析而不是運算
得來的 JS 物件,另外就是也不需要加上 CORS  Header,畢竟很多情形下要改
HTTP Header 好像非常的困難(就像大家抱怨 AppCache 要求
text/cache-manifest 一樣,現在標準已經不要求這個了)。

Google 的知名 ECMAScript 專家 Mark Miller 覺得說有一個穿透跨來源策略的特
殊值不是很好,問說能不能 xhr 回傳值是能用 JS 解析就允許跨來源,然後就討
論到可以從 xhr 得到 JS 到底有沒有比從 <script> 得到 JS 的資訊量多的有趣
問題。有些講到 ES3 的我不是很懂,不過好像因為有
Function.prototype.toString,所以 xhr 得到的 JS 比 <script> 的資訊量多在
「註解」而已(局部變數的名稱也可以靠 Function.prototype.toString 得到。
Function.prototype.toString 也是一個 implementation-dependent 的坑,不過
應該沒有瀏覽器會回傳註解...)。不過 Jonas Sicking 是說這個方案被採用的
話,隨便人都可以擷取本來是同來源的伺服器 <-> 瀏覽器 xhr JSON 溝通。(所
以剛剛那邊除了「註解」也外應該還包括在函數外沒被賦值的表達式 :p)

所以總之,以後 xhr 應該就可以弄跨來源的 JSONP 了。Jonas 是說他覺得
xhr.responseType="jsonp" 很醜(hideous),所以如果有人有什麼這個 API 的
命名建議的話可以提一下(可能可以 xhr.responseType = "json"; 再
xhr.enableJSONP(); 之類的... 不過感覺還是一句 xhr.responseType="jsonp"

(除了開頭的連結之外,我也把討論連結加到翻譯一半的 XMLHttpRequest 規範

[1] 這個部份的規範是[2],也蠻值得翻譯的,目前只有 FF 在這裡符合規範。
[3] http://www.w3.org/html/ig/zh/wiki/XMLHttpRequest


呂 康豪(Kenny), 中文興趣小組W3C連絡人
Google+: https://plus.google.com/112088462407783855918/posts
新浪微博: http://t.sina.com.cn/1950042164

(11/12/08 9:20), Jonas Sicking wrote:
> On Wed, Dec 7, 2011 at 3:55 PM, Yehuda Katz <wycats@gmail.com> wrote:
>> Yehuda Katz
>> (ph) 718.877.1325
>> On Wed, Dec 7, 2011 at 3:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Wed, Dec 7, 2011 at 12:39 PM, Yehuda Katz <wycats@gmail.com> wrote:
>>>> Yehuda Katz
>>>> (ph) 718.877.1325
>>>> On Wed, Dec 7, 2011 at 12:29 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>>> On 12/7/11 3:22 PM, Joshua Bell wrote:
>>>>>> This can't be implemented in JS today (e.g. as a shim) since that
>>>>>> "evaluate
>>>>>> this script text in this new global sandbox" bit isn't present.
>>>>> It can sort of be done via opening a new window and setting its opener
>>>>> to
>>>>> null before injecting some <script> tags into it.  Modulo popup
>>>>> blockers
>>>>> and crappy user experience, of course....
>>>> Or evaluating the script inside a worker, perhaps?
>>> Workers aren't great sandboxes. They already have access to shared
>>> workers and XHR. Soon they will get access to IndexedDB too. So
>>> there's lots of damage they can cause.
>>> If we want to run untrusted code then I think we need to have an API
>>> specifically designed for that.
>>> If we want an API for loading JSONP data apart from the sandbox (which
>>> I think is needed), then we should have an API specifically designed
>>> for that. It's possible that we can reuse XHR here and just adjust the
>>> security model when the returned data is JSONP.
>> You would at least want to execute them in a lexical scope containing the
>> callback, so that the callback did not need to be installed on the global
>> scope.
> Ideally we wouldn't execute anything. We'd just parse the JSON literal
> and hand that back. That is what'll give us safety.
> To make a concrete, but hideous, example:
> We could add xhr.responseType = "jsonp".
> When this is set, the XHR object will look for contents on the following form:
> <js identifier> '(' <js-literal> ')'
> followed by an optional ';'
> When the contents follows that syntax, the XHR object parses the
> js-literal and sets it's .response property to the result.
> Other than that the XHR object works just as it currently does. I.e.
> it fires progress events, load events and readystatechange events as
> normal.
> This way no JS execution happens, and no global names need to be set
> up. The <js identifier> part is simply ignored other than to check
> that it's a valid js identifier.
> I believe we can come up with something better than this, but it's a
> demonstration of what's technically feasible.
> / Jonas
Received on Thursday, 22 December 2011 20:44:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:49 UTC