data: URL処理器

data: URL

[10] data: は、 fetch の結果得られるデータそのものを URL 中に含めることができる URL scheme です。

仕様書

データモデル

[105] data: URL構造体 (data: URL struct) は、 MIME型本体を持つ構造体です >>97

構文

[129] data: URL は、 URL scheme の後に MIME型,本体を連結したものです。 他の URL scheme 同様に素片識別子を使うこともできます。

  1. data:
  2. MIME型
  3. ,
  4. 本体
  5. ?
    1. 素片識別子

[130] data: URL における MIME型は、 URL に含まれるデータの MIME型を表しています。 一般的な MIME型とはいくつか異なる点があります。

  1. |
    1. MIME型
    2. =
      1. 空白
      2. *
        1. =
          1. ;
          2. 空白
          3. 引数
          4. 空白
  2. ?
    1. ;
    2. 空白
    3. base64

[135] 本体は、 URL に含まれるデータを表しています。 任意のバイト列を表現できますが、 URL の構文上の制約から適宜パーセント符号化が必要です。

[136] ;base64 を指定した場合は、 表現するバイト列そのものではなく、 それを Base64符号化した結果を使います。

URL安全Base64などのバリエーションではなく、 通常の Base64 を使います。詰めは必須で、改行を挿入する必要はありません。

[137] 仕様上は長さの制限もありませんが、 現実的には実装依存URL の長さの制限を超えない必要があります。

構文解析

[106] data: URL構文解析は、 まずURLの構文解析を行った後、 data: URL処理器により処理させることで行なえます。

[107] data: URL処理器 (data: URL processor) は、 URL記録について、 次のようにします >>97

  1. [108] 入力を、 URL記録URL直列化器素片除外フラグ付きで適用した結果に設定します。
  2. [112] 入力, が含まれない場合、
    1. [113] 失敗を返し、ここで停止します。
  3. [115] 入力を、最初の , で分割し、 MIME型文字列に直前までを、 符号化本体に直後からを設定します。
  4. [116] MIME型文字列の先頭から data: を除去します。
  5. [111] MIME型文字列の先頭と末尾の ASCII空白をすべて除去します。
  6. [109] 本体を、符号化本体文字列パーセント復号を適用した結果に設定します。
  7. [110] MIME型文字列の末尾に ;、0個以上U+0020ASCII大文字・小文字不区別base64 の列がある場合、
    1. [120] これをMIME型文字列から除去します。
    2. [114] 文字列本体を、本体同型復号を適用した結果に設定します。
    3. [117] 本体を、文字列本体forgiving-base64 decode を適用した結果に設定します。
    4. [118] 本体失敗の場合、
        1. [119] 失敗を返し、ここで停止します。
  8. [121] MIME型文字列の先頭が ; の場合、
    1. [122] MIME型文字列の先頭に text/plain を挿入します。
  9. [123] MIME型を、MIME型文字列MIME型を構文解析する処理を適用した結果に設定します。
  10. [124] MIME型失敗の場合、
    1. [125] MIME型を、 text/plain;charset=US-ASCIIMIME型を構文解析する処理を適用した結果に設定します。
  11. [126] 新しい data: URL構造体を返します。
    [127] data: URL構造体
    MIME型
    MIME型
    本体
    本体
[128] URL記録をすぐにURL直列化器文字列に戻していますが、 URLの構文解析の時点で正準化が行われるため、 data: URL文字列をそのまま与えるのとは違います。

[144] この処理は scheme fetch で呼び出されます。

fetch

[138] data: URL についての scheme fetch は、要求について次のようにします >>96

  1. [139] 構造体を、 要求現在URLについて data: URL処理器を実行した結果に設定します。
  2. [140] 構造体失敗の場合、
    1. [141] ネットワークエラーを返し、ここで停止します。
  3. [142] 新しい応答を返します。
    [143] 応答
    状態メッセージ
    OK
    ヘッダーリスト
    Content-Type
    構造体MIME型MIME型をバイト列に直列化する処理を適用した結果
    本体
    構造体本体
    HTTPS状態
    要求クライアントnull でない場合、 要求クライアントHTTPS状態

テスト

[104] web-platform-tests/fetch/data-urls at master · w3c/web-platform-tests () <https://github.com/w3c/web-platform-tests/tree/master/fetch/data-urls>

[19] data: URL tests (2008-05-15 05:24:13 +09:00 版) <http://www.mozilla.org/quality/networking/testing/datatests.html>

[20] Opera Browser Wiki :: Data: URI Test Page (2008-05-18 19:13:55 +09:00 版) <http://operawiki.info/DataURIs>

[21] Index of /tests/adhoc/data (2008-05-18 19:24:49 +09:00 版) <http://www.hixie.ch/tests/adhoc/data/>

[35] data: URIs (2008-06-01 20:50:55 +09:00 版) <http://suika.fam.cx/~wakaba/-temp/test/uri/data/test.cgi#>

関連

[47] canvas 要素toDataURL メソッドは、 レンダリングされている画像data: URL として符号化して返します。 JavaScript には元々バイナリーを表すデータ型がなかったので、 JavaScript / DOM画像のデータを表現する唯一の方法として data: URL文字列が利用されています。

[48] 現在では Blob もありますが。

セキュリティー

[84] フィッシングに使われた例が報告されています >>83

歴史

RFC 2397 時代

構文

[22] (他の URI scheme 同様) data: URI scheme の仕様は非常に曖昧です。古い時代の仕様書なので仕方がありませんが、 どこまでが規定でどこからが参考なのかも明確ではありません。

[12] 構文の概要: RFC 2397 の2章によると、 data: URI の構文を簡単にあらわすと

data:[<mediatype>][;base64],<data>

となります。

[13] 構文の定義: RFC 2397 の3章は更に詳しく

  • dataurl := "data:" [ mediatype ] [ ";base64" ] "," data
  • mediatype := [ type "/" subtype ] *( ";" parameter )
  • data := *urlchar
  • parameter := attribute "=" value
- urlchar: RFC 2396 の定義を参照

と定義しています。

[23] 構文の定義自体の問題: 自明だからどうでも良いと思ったのか、 この構文定義自体が何で書かれているのか説明がありませんwwwww ABNF の一種だろうと思いますが・・・。

[24] urlc: urlcRFC 2396 の定義を参照していることになっていますが、 実のところ RFC 2396urlc は定義されていません。 おそらく uric の誤りなのでしょうが、これは致命的です。

そもそも、 RFC 2396 を参照しておきながらなぜ URL scheme なのかが謎です。

[14] value: valueRFC 2045token または quoted-string と定義されています。しかし、 quoted-string は URI で直接使えない (unsafe な) "\ を使います。 つまり、構文通り解釈すると使えるはずのものが URI 仕様との整合性を考慮すると使えないのです。

実は使えないのはこの2文字だけではなく、改行を含むC0制御文字空白なども URI ではそのまま使えません。更に、この value や、 token として定義されている attribute には % を含めることができますが、 URI では %百分率符号化のための特別な文字として使われます。

[25] 百分率符号化: RFC 2397著者も馬鹿ではありませんから、百分率符号化 (当時の名称は URI逃避符号化RFC 2396 における呼称は URL逃避符号化) との関係に言及しています。

[26] まず一点目に、必要に応じて百分率符号化を用いて表現するとの旨が規定されています RFC 2397 3.:

   (ABNF 構文定義)
   where "urlchar" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

この最後の部分がどこに係っているのかが曖昧なので、3通りの解釈が可能です:

普通修飾するのは直前のものでしょうから、3つ目の解釈は少々無理があるかもしれませんが、 あり得ないとまではいえません。ちなみに3つ目の解釈に従うなら base64 の部分に百分率符号化が使えます。 1つ目と2つ目の解釈の違いは urlc百分率符号化が使えるか否かですが、 そもそも uric には escaped (百分率符号化) が含まれているので、どちらでも同じことになります。

as necessary というのも曲者で、穿った読み方をすれば、 必要でない場合には使ってもよいとされていないとも解釈し得ます。 (流石にこれは深読みしすぎでしょうが。)

[27] 2点目に、value での百分率符号化について、

   However, within a "data" URL, the
   "quoted-string" representation would be awkward, since the quote mark
   is itself not a valid urlchar. For this reason, parameter values
   should use the URL Escaped encoding instead of quoted string if the
   parameter values contain any "tspecial".

と言及しています RFC 2397 3.。ここで、 前述の構文が百分率符号化込みのものと理解するべきかという問題が発生します。 この引用部をそのまま解釈すると、 token の部分に百分率符号化が使えることになります。

token を定義している RFC 2045URI のことなど気にしていないので、当然百分率符号化が使えるかどうか、 その使い方には言及していません。ただし、token で使える文字には % が含まれています (この辺の事情は引用部の should not を無視して quoted-string を使う場合にも該当します)。 たとえば 100%!妥当token です。しかし、 16進数字が2つ続かない %URI で使うことはできません。 URI の仕様に従うなら、 百分率記号を表したいときは %25 と書かなければなりません。

[28] また、百分率符号化を前述の部分のどんな文字にも使ってよいのかも明確ではありません。 たとえば subtypesvg+xml であったとして、 URIsvg+xm%6C と書いても、 (どんな URI scheme でも非予約文字百分率符号化してもしなくても等価なので) 問題ありません。 しかし、 svg%2Bxml が前2例と等価であるのか否かは明らかではありません。 (+reserved なので。) 意図としては百分率符号化を使っても構わないのでしょうが。。。

URI の構文の一部に URI 以外のプロトコル要素の定義を引用することはよくありますが、 このような解釈の問題が起きないように、慎重に設計することをお願いしたいものです。

[15] Base64: また、 ";base64" が指定されると、 dataBase64 と解釈されます。 (この指定で大文字と小文字が区別されるかどうかがよくわからないのも問題です。)

ところが、その Base64 の定義が何を参照しているのかが全然書かれていません。 他のところで RFC 2045 を参照しているので、そこで定義されているものと解釈するのが一番もっともらしそうですが、 Base64 は色々な変種が知られているので、油断できません。 (その変種のほとんどが、 RFC 2045 の MIME にべったりな部分に手を加えたものです。)

たとえば、改行や空白の問題があります。 RFC 2045 の Base64 では一行の字数制限があるのですが、それが適用されるかどうかわかりません。

4. には次のような例が載っています。

   <IMG
   SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
   AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
   ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
   a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
   ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
   F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
   hhx4dbgYKAAA7"
   ALT="Larry">

行頭の間隔は RFC としての余白です。 それを無視したとしても、行を折り返しているのが RFC としての行字数制約によるだけで本来いれてはならないものなのか、 RFC の制限だけど実際にも入れてもよい ものなのか、説明が全然ありません。 (かりに入れてもよいとしても、 URI 逃避符号化しない限り URI 全体の構文に違反しますがね。)

[16] >>15 のようなことが気になるのは、実際に生の改行入りで XLink の属性なんかに指定した例が存在するからです。 (XLink の xlink:href 属性値は URI参照そのものではなく、 URI 逃避符号化すれば URI 参照になるものなので、 XLink 的にも一般の URI 的にもこの指定自体は一応合法。)

[29] 空白: RFC 2045 MIMERFC 822 電子メイルの文脈で使う場合、 構文定義上は明記されていませんが、字句間に空白 (RFC 822 では LWScomment、後の RFC 2822 では CFWS) を挿入してもよいことになっています。 それに従えば type, subtype, attribute, value の前後に空白を挿入できることになりますが、 RFC 2397 ではそのことにまったく言及していません (>>23 で指摘したように、そもそも構文定義自体の記述方法の説明がありません)。

[30] RFC 2231 引数値拡張: RFC 2231RFC 2045Content-Type: 頭欄で用いられるような引数値の構文の拡張を定義しています。 data: URI scheme でこの拡張を使うことができるのかは不明です。

[31] 素片識別子: RFC 2397素片識別子にまったく言及していません。 RFC 2396素片識別子URI の一部ではなく、 URI参照の一部であるという立場をとっていたので (後の RFC 3986 では素片識別子URI の一部)、その考えに従っているのかもしれません。

Ian Hickson はかつて、 data: URI では素片識別子が使えないと主張していたように見えますが (>>21 にあるテストのソースを参照)、この事実以外に何か根拠があるのかは不明ですし、 現在もそのように主張しているのかは不明です。

[34] >>27 の引用部の本来の意図はどう読んでも quoted-string の代わりに token + 百分率符号化を使うのがよいなのですが、 >>27 のように解釈しても問題がありますし、value(百分率符号化を前提としていない RFC 2045 の構文規則なので) 百分率符号化を解いた後の文字列に対する構文規則である、と解釈しても問題があります。 tspecials を含むような文字列妥当token ではありませんから、 a%40b を元に戻した a@btoken 足りえません (元の意図は、 a@b"a@b" としなくてもよいとするもののはずです)

処理モデル

[32] 他の URI scheme の仕様書と同様、 RFC 2397data: URI scheme の構文を定義するだけで (それすらも前述のように満足にできていないわけですが)、 どのように処理するべきか、構文的に誤った data: URI をどう扱うべきかに一切言及していません。

[33] 百分率符号化された8ビット部: 百分率符号化されたオクテットがあった場合、 data 部なら指定された媒体型に従って解釈するのでいいのでしょうが、 それ以外の部分ならどう解釈するべきなのかが問題になり得ます。 typesubtypeattribute の部分はそもそも ASCII 文字だけで定義されているので、 8ビット部が ASCII に写像されない限りどう解釈しようが問題にはなりません。

たとえば8ビット目を落とすとか、UTF-8Unicode case-insensitive に処理したりすると問題になりますが。

value の部分は任意の文字列を指定し得るので、 文字コードが問題となります。MIME 的に正しいのはそれでもやはり ASCII 文字だけですが。。。

フォーム提出

[38] Web Forms 2.0 ( 版) <http://www.whatwg.org/specs/web-forms/current-work/#for-data>

[9] The data: URI kitchen <http://software.hixie.ch/utilities/cgi/data/data> 任意のデータから data: URI をつくってくれます。

[18] Bug 16968 - Security violations in Acid3 test (2008-01-22 20:19:03 +09:00 版) <http://bugs.webkit.org/show_bug.cgi?id=16968>

[36] 3ブラウザとも、 name 引数ファイル名に使うことはないようです。

[37] Protocol Handlers for Microsoft Internet Explorer - misuzilla.org (Mayuki Sawatari 著, 版) <http://www.misuzilla.org/dist/net/mphandler/>

[39] IRC logs: freenode / #whatwg / 20090928 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20090928#l-763>

[40] IRC logs: freenode / #whatwg / 20091112 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20091112#l-546>

[41] IRC logs: freenode / #whatwg / 20100129 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20100129>

[42] data Protocol ( 版) <http://msdn.microsoft.com/en-us/library/cc848897(VS.85).aspx>

[43] Inline Images on Web Pages ( ( 版)) <http://elf.org/essay/inline-image.html>

[44] img 要素src 属性に設定すると、すぐに (おそらく同期的に) 読み込む Gecko のようなブラウザと、そうではない WebKit のようなブラウザがあります。

[45] Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded) ( (Julian Reschke 著, 版)) <http://lists.w3.org/Archives/Public/public-iri/2011Apr/0066.html>

[46] Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded) ( (Boris Zbarsky 著, 版)) <http://lists.w3.org/Archives/Public/public-iri/2011Apr/0067.html>

[49] data url スキームとmidi ( ( 版)) <http://members3.jcom.home.ne.jp/nakamura7/dataurlschememidi.html>

[50] Web Applications 1.0 r6783 Drop <time> and replace it with <data>. Drop the Atom conversion section entirely. Convert a bunch of examples that used to use <time pubdate> to using schema.org, to show how to annotate publication dates and the like in a machine-processable way. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=6782&to=6783>

[51] Web Applications 1.0 r6855 Bring W3C specs back to tip of tree per chair request. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=6854&to=6855>

[52] IRC logs: freenode / #whatwg / 20120216 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120216>

[53] XMLHttpRequest ( ( 版)) <http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http>

[54] Web Applications 1.0 r7180 Make data: URLs officially work in Workers. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=7179&to=7180>

[55] DataURI Maximum length - latest log ( ( 版)) <http://uupaa.hatenablog.com/entry/2012/08/09/165800>

[56] [whatwg] data URLs and XMLHttpRequest ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037188.html>

[57] [whatwg] Security restriction allows content thievery ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037187.html>

[58] IRC logs: freenode / #whatwg / 20121126 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20121126>

[59] The "data" URL scheme ( ( 版)) <http://simonsapin.github.com/data-urls/>

[60] SimonSapin/data-urls · GitHub ( ( 版)) <https://github.com/SimonSapin/data-urls>

[61] IRC logs: freenode / #whatwg / 20121203 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20121203>

[62] IRC logs: freenode / #whatwg / 20121205 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20121205>

[63] IRC logs: freenode / #whatwg / 20130313 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130313>

[64] Fetch defines data URL handling. · a64eb7c · whatwg/xhr ( ( 版)) <https://github.com/whatwg/xhr/commit/a64eb7c2985d5ab83dca0c840ec1a95378935e11>

[65] Fetch defines data URL handling. · a64eb7c · whatwg/xhr ( ( 版)) <https://github.com/whatwg/xhr/commit/a64eb7c2985d5ab83dca0c840ec1a95378935e11>

[66] SVG2 Requirements Input - SVG ( ( 版)) <http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Gzip-compressed_svg_in_data_URIs>

[67] Clarify data URL dependency https://www.w3.org/Bugs/Public/show_bug.cgi?... · 13cbf9d · whatwg/fetch ( ( 版)) <https://github.com/whatwg/fetch/commit/13cbf9d18b70314dba5ed89251ed026d6d7b1dcf>

[68] Data URL loading is now controlled through a flag. Blob URLs have an ori... · 5b64685 · whatwg/fetch ( ( 版)) <https://github.com/whatwg/fetch/commit/5b64685a97a7d6f24814172de68399d0225a4cae>

[69] [whatwg] Stricter data URL policy ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-June/296963.html>

[70] RFC 6170 - Internet X.509 Public Key Infrastructure -- Certificate Image ( ( 版)) <https://tools.ietf.org/html/rfc6170#section-4>

[1] Ambiguities in the "data" URL scheme ( 版) <https://simonsapin.github.io/data-urls/>

[2] Set the same-origin data-URL flag. Set request's destination rather t… · whatwg/xhr@59d4f5b ( 版) <https://github.com/whatwg/xhr/commit/59d4f5b4b49b3ba0f0a491dbdf83865cf3d285b7>

[3] Fix #111: forbid redirects to data URLs · whatwg/fetch@f986c43 ( 版) <https://github.com/whatwg/fetch/commit/f986c43f958a0f7ffdc46553d5a53a0c56a89a32>

[4] 1018872 – Implement stricter data URL policy ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=1018872>

[5] Fix #337: perform origin checks for workers in Fetch · whatwg/html@e86b2e4 ( 版) <https://github.com/whatwg/html/commit/e86b2e4b8fdef45404c61c1a85c40da7edf8b561>

[6] Revert #111: allow redirects to data URLs · whatwg/fetch@31f65e4 ( 版) <https://github.com/whatwg/fetch/commit/31f65e4625eacb3a74b5d1eba905d0600040c6ce>

[7] Fix #176: set request's same-origin data-URL flag for <img> · whatwg/html@b09402f ( 版) <https://github.com/whatwg/html/commit/b09402f7f1f910bcb6025cfd255b0b7291f300a6>

[8] Give user entered data: URI documents the HTTPS state 'modern' · Issue #243 · whatwg/fetch ( ()) <https://github.com/whatwg/fetch/issues/243>

[17] Remove the note about data: and blob URLs (fixes #35) ( (fmarier著, )) <https://github.com/w3c/webappsec-subresource-integrity/commit/ef5f92bbe1a7a849b215bc1761cee41e8a01824e>

[71] Fix form submission for the data URL scheme ( (annevk著, )) <https://github.com/whatwg/html/commit/e2d80d9285976c6c38bda188c59e97456006d0a3>

[72] Androidの標準ブラウザでbase64の画像を保存しようとすると落ちる問題 - Qiita ( ()) <http://qiita.com/mo49/items/4957acea626c9e07cee3>

base64はURLが長すぎるので、一部Androidの標準ブラウザでは画像を長押し保存できない

[73] Remove the GET method restriction for data URLs (annevk著, ) <https://github.com/whatwg/fetch/commit/c4cb4f4a5fa90a72f1000449495aec04f6c8c96b>

[74] How to: Add Silverlight to a Web Page by Using HTML () <https://msdn.microsoft.com/en-us/library/cc189089(v=vs.95).aspx>

<object width="300" height="300"

data="data:application/x-silverlight-2,"

type="application/x-silverlight-2" >

<param name="source" value="SilverlightApplication1.xap"/>

</object>

[75] Set same-origin data-URL flag for <img> when environment changes (zcorpan著, ) <https://github.com/whatwg/html/commit/208ff6e3bb16b6c31c0dd3f19ed70370cc5aa628>

[76] Treat 'data:' documents as unique, opaque origins (#1756) (mikewest著, ) <https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f>

[77] Fiddle with progress events (annevk著, ) <https://github.com/whatwg/xhr/commit/01da69fb27d10a3315f9bf8259cc7074713379ee>

[78] Treat data URLs as same-origin (annevk著, ) <https://github.com/whatwg/fetch/commit/6f223de29733e64dbe1dfc6028c6e0a4a5d89398>

[79] Define how data URLs affect workers (annevk著, ) <https://github.com/whatwg/html/commit/c592f62985ab9aa0e26c111a9823de5101d58c96>

[80] Remove Fetch's same-origin data URL flag (annevk著, ) <https://github.com/whatwg/html/commit/7204ca9d0f6ac8b2439c9b77a1c4ff988de0b7e3>

[81] 123004 - incorrect handling of fragment identifiers in data: URIs - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=123004>

[82] Re: Bug in Acid3 test #72 (race condition when images decode asynchronously) (Simon Pieters著, ) <https://lists.w3.org/Archives/Public/www-archive/2017Jan/0000.html>

[85] New in Chrome 58  |  Web  |  Google Developers () <https://developers.google.com/web/updates/2017/04/nic58>

[86] 737419 - Implement <data> element - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=737419>

[87] Deprecations and Removals in Chrome 60  |  Web  |  Google Developers () <https://developers.google.com/web/updates/2017/06/chrome-60-deprecations>

[88] 684011 - Remove: Top frame navigations to data URLs - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=684011&desc=2>

[89] Testing data URLs () <https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985>

[90] Ambiguities in the "data" URL scheme () <https://simonsapin.github.io/data-urls/>

[91] SimonSapin/data-urls: Filling the gaps in RFC 2397. () <https://github.com/SimonSapin/data-urls>

[92] 175568 – data: URL base64 handling different from atob() () <https://bugs.webkit.org/show_bug.cgi?id=175568>

[93] Treating data URLs as unique origins for Firefox 57 | Mozilla Security Blog () <https://blog.mozilla.org/security/2017/10/04/treating-data-urls-unique-origins-firefox-57/>

[94] jsdom/data-url: Parse data: URLs () <https://github.com/jsdom/data-url>

[95] Define data: URL processing (annevk著, ) <https://github.com/whatwg/fetch/commit/36ef3c8aef34ff77ebf713b6498d008fe853034f>

[98] data URLs: revised specification · Issue #234 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/234>

[99] Define data: URLs by annevk · Pull Request #579 · whatwg/fetch () <https://github.com/whatwg/fetch/pull/579>

[100] 1392241 - Align with Fetch on data: URLs () <https://bugzilla.mozilla.org/show_bug.cgi?id=1392241>

[101] data: URL processing and generalized forgiving-base64 decode tests (annevk著, ) <https://github.com/w3c/web-platform-tests/commit/7eec2bf5e522d28d99ced501b0f49477c3b105d5>

[102] data: URL tests by annevk · Pull Request #6890 · w3c/web-platform-tests () <https://github.com/w3c/web-platform-tests/pull/6890>

[103] web-platform-tests/data-urls.json at master · w3c/web-platform-tests () <https://github.com/w3c/web-platform-tests/blob/master/fetch/data-urls/resources/data-urls.json>

[134] Make status message default to the empty byte sequence (annevk著, ) <https://github.com/whatwg/fetch/commit/0dec453f642c1fe57e6e7627c9a66cf7f8b8394d>