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

可以解釋一下 xhr.responseType = "jsonp"; 的行為嗎？
是說這樣 callback= 這個參數還要自己加嗎，還是 xhr 會自動加上去？
因為現有的 server 實作是：

* JSONP: allow cross-origin
* JSON: does NOT allow cross-origin

如果不需要傳 callback= 就可以把 JSON 的內容當成 JSONP 抓下來解析的話，會天下大亂 ...
具體的例子是 Plurk API v1。
然後要傳要接收驗證的話就回到 JSONP 被人詬病的不能 cache，不能 serve static file 的問題 :(

我是覺得這個功能很好啦，是很好的 adoption path（會用 JSONP 的人很容易學的會），但是不是取代 CORS 標準的方法。


Tim


2011/12/23 Kang-Hao (Kenny) Lu <kennyluck@w3.org>:
> 轉一個有趣的討論串。來源：http://lists.whatwg.org/htdig.cgi/whatwg-
> 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 規範
> [3]了，希望增加規範翻譯的價值。歡迎大家陸續加入！）
>
> [1] 這個部份的規範是[2]，也蠻值得翻譯的，目前只有 FF 在這裡符合規範。
> [2]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#script-processing-src-prepare
> [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 Friday, 23 December 2011 03:14:22 UTC