x-scheme-handler/https

http: URL, https: URL

[14] http: は、 HTTP over TCP によってアクセスできる資源を表す URL scheme です。

[121] https: は、 HTTP over TLS/SSL (HTTPS) によってアクセスできる資源を表す URL scheme です。

[66] 両者の総称を HTTP(S) scheme といいます >>67

仕様書

意味

[19] http: URL は、指定された hostportHTTP over TCP で接続し、 pathqueryRequest-URI として指定したときに得られる資源を識別しています。 >>18, RFC 2616 正誤表, >>125

しかし Opportunistic Security for HTTP/2 のように HTTPS を使う場合も (理論上は) あります。

[133] https: URL は、指定された hostportHTTP over TLS over TCP で接続し、 pathqueryRequest-URI として指定したときに得られる資源を識別しています。 >>125

[134] RFC 7230 の定義上 TLS に限定されており、 SSL は含まれていません。

[444] 両者は異なる名前空間起源鯖を表すものですから、 たとえホストポートが同じであっても、 pathquery によって識別される資源が共通であるとは限りません >>125

[52] HTTP/0.9HTTP/1.0HTTP/1.1 >>125HTTP/2 >>51 のいずれも http:/https: URL scheme を使います。 URL のみによってプロトコルの版を特定・指定することはできません。


[15] Semantic Web の世界では、実際には HTTP でアクセスしても存在していない資源や、 HTTP によってメタデータが取得できるに過ぎない資源にも http: URL が濫用されています。

[139] Semantic Web の世界は RDF で表される世界内部の「意味」 は重視しますが、 HTTPURL の「意味」には無関心な印象があります。

構文

[127] RFC 7230 は、 RFC 3986 に基づき http: URI scheme の構文を次のように定義しています >>125

     http-URI = "http:" "//" authority path-abempty [ "?" query ]
                [ "#" fragment ]

[135] RFC 7230 は、 RFC 3986 に基づき https: URI scheme の構文を次のように定義しています >>125

     https-URI = "https:" "//" authority path-abempty [ "?" query ]
                 [ "#" fragment ]

authority

登録名

[130] host登録名であれば、これは DNS などの名前解決サービスによって起源鯖アドレスを探すための間接識別子です。 >>125

IP アドレス

[129] hostIPアドレスであれば、起源鯖がそのIPアドレスTCPlisten しているかもしれないことを表しています。 >>125

[81] RFC 2616 は、IPアドレスを使うことは可能な限り避けるべき >>18 としていました。

空文字列

[128] 送信者は空の host生成してはなりません受信者非妥当であるとして拒絶しなければなりません>>125

port

[20] http: URL では、 ポートがないかであるときの既定のポート80 です >>18, >>125

[136] https: URL では、 ポートがないかであるときの既定のポート443 です >>125

[75] 利用されるポート番号については、HTTP接続TCP の項を参照。

userinfo

[131] 構文上 userinfo も利用できます。実装によっては userinfo認証情報として使います >>125

[132] しかし送信者要求対象ヘッダーの値として含まれる http:/https: URL において userinfo生成してはなりません >>125

[87] 旧仕様上は、 userinfo を使うことは認められていませんでした。 これは >>97 から RFC 2616 (>>86) までずっと変わっていませんでした。
[98] 認められなかったというよりは、単に追加されなかっただけでしょうな。 初期の HTTP には認証が何も実装されていませんでしたから。

串における処理

[83] は、ホスト名FQDN でなければ、ホスト名を追加して構いませんFQDN は書き換えてはなりません>>18

パス

[23] パスによって解釈されます。パス/パスセグメントを繰り返したものと定義されてはいますが、 前後の区切り文字やパーセント符号化を除けば事実上任意の文字列を使うことができます。

  1. *
    1. /
    2. パスセグメント

[82] path が省略されている (空文字列である) 場合、 HTTP 要求Request-URI としては「/」を使わなければなりません >>18

パスの階層化

[24] パスにはほとんど任意の文字列が認められるとはいえ、多くの場合は以降で述べる通り、 最後以外のパスセグメントディレクトリーなどの階層、 最後のパスセグメントファイルなど階層内のオブジェクトを表すものとして扱っています。 ファイルシステムURL を対応付けていない場合であっても、 同様の仮想的な階層構造でパスを設計するのが一般的です。

[25] 次のものは、そのような一般的な階層構造を想定して作られていたり、 一般的な階層構造の場合に最も使いやすくなっていたりします。

[78] ディレクトリーURLも参照。

階層区切り文字

[74] サービスワーカーの適用範囲の指定では、 パーセント符号化された /\ にあたる %2F%5C が含まれている時、エラーとして扱います。 サーバーの不具合を突いた攻撃を防ぐためなのでしょう。

登録開始参照。

[76] CGI を実装するサーバーによっては、 PATH_INFOパーセント符号化された / にあたる %2F が含まれている時、エラーとして扱うことがあります。

PATH_INFO 参照。

ディレクトリーを表す path

[107] http: URLpath の末尾が / で終わる場合、 ファイル・システムの類似の概念になぞらえて「ディレクトリー」や「フォルダー」 と呼ぶことがあります。

詳しくはディレクトリーURLを参照。

拡張子

[110] http: URLpath の末尾が . と数文字の英数字で終わる場合、ファイル・システムの類似の概念になぞらえて「拡張子」 と呼ぶことがあります。 URL の仕様上も HTTP でも「拡張子」 という概念は存在しませんが、 http: URLpathファイル・システムpath に対応付けることがしばしばあるため、 慣用的に用いられています。

[111] HTTP の仕様上は不透明な path の一部でありプロトコル上やクライアントの動作には影響しないはずですが、 便宜上、利用者エージェントの一部の動作に影響することがあります。例えば、 http: URL拡張子画像を表すものかどうかによって挙動が変わることがあります。

[112] HTTP の仕様の想定としては実際にアクセスして Content-Type を見て挙動を変えるのが適切なのでしょうが、 URL だけを見て、 ネットワーク・アクセスを発生させずに挙動を決定するには拡張子が便利なので、 しばしば用いられるのです。

[3] 掲示板の類で利用者が入力した URLリンクまたは画像に変換するシステムでは、 拡張子によってリンク画像かを決定することがあります。

[9] キャッシュ串の中には、拡張子キャッシュするかどうかの判断条件に使うものがあります。

[113] 拡張子は、 HTTP において HTTP 実体頭欄を決定したり、内容折衝を行ったりする際の情報として利用されることがあります。 例えば Apachemod_mime は、 AddTypeAddCharset などの指令によって決まる拡張子MIME型などの対応情報に基づき、 Content-Type 頭欄などを決定したり、内容折衝を行ったりします。

[114] 内容折衝などを活用することにより HTTPhttp: URL を (表現より一段抽象化された) 資源として捉えることを好む人達は、 URL拡張子が含まれることは好ましくないと考えています。 拡張子を含めなければ、 GIFPNG の2種類がに用意されているときに、 クライアントが送ってきた Accept: 頭欄を見てどちらか適切な方を返すことができるからです。

[115] 実際に Apache ではファイル・システム上の拡張子付きのファイルに対して拡張子を除去した URL を使ってアクセスして内容折衝を行わせることができます。

[10] MIME型の他、言語などを表す拡張子を組み合わせて ApacheAddTypeAddLanguage などに対応づけることがあります。

[21] 例えば URL path /document.ja.html.utf-8 によって Content-Language: ja, Content-Type: text/html; charset=utf-8生成するように設定されていることがあります。

[57] .cgi.asp.exe のように、 応答の種類をまったく表さず、専らサーバー側で実行するべき処理の手段を表すもの (Apache では AddHandler で使うもの) もよく用いられています。

予約されている path

[99] 次に述べる path は、 http: および https: で公式または非公式に予約されていて、特定の目的に使われます。

[79] 特別な意味を持つ HTTP(S) URL パス

[144] 関連: 特別なファイル名

ホームディレクトリー

[102] http://host/~username/path のような URL は、利用者 username に割り当てられた領域を意味するものとして使う慣習があります。 host は通常は ISP大学などの所有するドメイン名であり、 会員教員学生Web 公開用の領域として割り当てています。

[103] ~ は、 Unixホームディレクトリーを表す記号として用いられていて、 それをそのまま URL として使っているものと推測されます。

[104] Apache などの普及している HTTP の既定の設定においては、 /~username/ファイルシステム上の ~username/public_html/ に対応します。

[105] 近年では組織が構成員に Web 用の領域を割り当て、 そこを使って Webサイトを公開することが少なくなってきたので、 この形式の URL を見ることも減ってきました。

[106] なお、 ~ は古い RFC では使用が認められておらず、 %7E百分率符号化しなければならなかったにも関わらず、 この慣習は広く行われており、 ~ をそのまま使った URL も昔からよく見かけました。結局 ~ は仕様上も追認されることになるのですが、 それまでは %7E と書くべきだとか、そもそも ~ を使うのは好ましくないだとかいった議論がしばしばなされました。

params

[54] 過去の URL 仕様では、 pathparams (; から始まる引数列) が区別されていたこともありました。しかし http:/https: URL で実際に区別して扱われることは無いようです。

comma tools

[55] W3CWebサーバー http://www.w3.org/ では comma tools と称して、通常の URLpath の末尾に ,tools のような指定を加えて http://www.w3.org/,tools のようにすることで、 元の URL に対して便利ツールを呼び出すことができるように設定されていました。

[56] これは当該サーバーのみの独自のサーバー側の処理で、クライアント側で特別な扱いもされていませんでしたし、 何らかの標準化を試みたものでもなかったようです。 W3C 以外で同様の仕組みを実装した例はほとんどありません。

CGI と派生仕様におけるパス

[120] スクリプトURLSCRIPT_NAME, PATH_INFO, PATH_TRANSLATED を参照。

WebDAV における制約

[35] WebDAV に適合する資源は、次の「HTTP URL 名前空間モデル」 に対応しなければなりません >>34

[36] HTTP URL 名前空間は、 / を階層区切り文字とする階層化された名前空間です >>34

[37] HTTP URL 名前空間は、 HTTP 階層中のすべてのURL について、 その URL内部メンバーURLとして含むコレクションが存在するなら、 一貫している (consistent) といいます。 ただし、対象となる名前空間 (最上位コレクション) を除きます。 >>34

[38] ここでいう「」は必ずしもパス / でなくても構いません。 /servlets/webdav/ のようなものでも構いません。 >>34

[39] HTTP URL 名前空間の全体が一貫していることは要求されていません。 従って WebDAV に適合する資源であってもとなるコレクションが存在しないこともあります。 しかし、いくつかの WebDAVメソッドは、 名前空間が一貫しなくなるような操作を禁止しています。 >>34

[40] コレクションに関する制約は、コレクションの項を参照。

階層以外の利用例

存在確認

[62] Webサイトの所有者の確認を参照。

設計

[108] URL設計参照。

query

[58] query の構文と意味は HTTP 仕様としては規定されておらず、 解釈はサーバーに委ねられています。

[59] HTML では、フォームの提出などで使う application/x-www-form-urlencoded 形式の query が規定されています。しかしこれはあくまでフォームなどの HTML の機能を使って HTTP 要求を生成する場合に限った規定であり、 リンクURL などそれ以外の文脈では、サーバーが好きな構文と意味を採用できます。

詳細や実際の利用状況については query も参照。

素片識別子

[60] 素片識別子の利用に関する制約は特にありません。応答として返される MIME型の規定に従い任意の素片識別子を利用できます。

素片識別子も参照。

長さ

[94] URLの長さを参照してください。

比較と正規化

[92] HTTPにおけるURLの比較を参照してください。

名前空間や識別子としての HTTP URL

[26] http: URL を (Webページにアクセスするためのアドレスではなく) 何らかの概念を指す識別子として使うことを好む人がいます。

[27] Semantic Web 界隈などに多くいるようです。

[28] URL を識別子として使うことを好む人の中には URNXRI などを好む人もいますが、 http: を好む人は、それらは名前空間文書へのアクセス手段に乏しいため好ましくないと主張しているようです。

[30] 識別子として使われる HTTP URL は、 (>>28 のような主張の期待に背いて) HTTP でアクセスしても適切な文書が存在しないことがよくあります。 定義された瞬間は存在しても、その後メンテナンスがなされなくなり 404 になる、というのは良い方で、 最初から存在しなかったり、そもそもHTTP鯖が存在しなかったりすることも珍しくはありません。

[31] メンテナンスがされなくなった後ドメインの所有者が変わっていることもあり、 そのような問題を避けるために PURL を使ったものの、そのリダイレクト先がなくなっている事例もあったりします。

[32] アクセスが可能でも、リダイレクトされて他の URL で何らかの文書スキーマが提供されていることもよくあります。 これは名前空間URLコピペするときに誤った値にしてしまう要因の一つとなっています。

[33] HTML名前空間 http://www.w3.org/1999/xhtml にアクセスすると http://www.w3.org/1999/xhtml/リダイレクトされるので、後者の URL を使う人もいますが、 正しくありません。

URL scheme のバリエーション

[47] HTTPHTTPShttp:https: のような本来の URL scheme の他に、 HTTP 上で動作するプロトコルHTTP を利用するアプリケーションは、そのプロトコルアプリケーションに適用範囲が限定される以外は http:https: と変わらない URL scheme を使っていることがあります。

[48] 例えば次のようなものがあります。

[49] 掲示板等では URL自動リンクを回避するため、敢えて URL scheme の一部を省略したり、書き換えたりすることがあります。

[50] HTTP と関連が深いプロトコルである WebSocket は、次の URL scheme を使います。構文も非常によく似ています。

処理

フォーム提出

[11] フォームの提出を参照。

文脈

[61] HTTPにおけるURLを参照。

不思議解釈

[4]

RFC 2616 には HTTPプロトコルに関することが書かれており,3.2.2 http URL に書かれている http URL も,HTTPプロトコルの中での話になります.一般に,HTML のリンクに使用されるものは,純粋に HTTPプロトコルの中で使用される http URL ではなく, scheme が http であるURI References です.

出典: Perlメモ http://www.din.or.jp/%7Eohzaki/perl.htm#httpURL (2005年3月現在)

このような解釈は正しくありませんIANAURI scheme 登録簿に拠れば http: URI scheme の出典は RFC 2616 であり、 IETF 的に有効な http: URI の規定は (HTTP であれ HTML であれ、その他の文脈であれ) RFC 2616 だけです。

更に

たとえば http://user:passwd@www.din.or.jp/~ohzaki/perl.htm#URI は URI References ですが,user:passwd@ の部分,すなわち,userinfo や,#URI の部分,すなわち, Fragment Identifier は HTTPプロトコルの中で使用される http URL としては不正なものとなります.しかし,HTML のリンクとしては問題ありません.なぜなら,クライアント(ブラウザ)が HTTPプロトコルで通信する際にはそれらを削除しているからです.

と説明がありますが、このような議論は実装がそうであるというだけで、 仕様がそうであるとの根拠はありません。 (RFC 2396 の時代に URI参照の一部分ではあっても URI の一部分ではなかった素片識別子は別として、) 単に仕様と実世界が整合していないというだけであって、 HTTP で使うか HTML で使うかは関係ありません。

個々の URI scheme の規定は RFC 2396 (や新しい RFC 3986) の一般の規定に優先するので、 RFC 2396 で許されるように見えても RFC 2616 で許されないものは、すべて認められません。

(ftp: URI に関する部分にも同様の指摘ができます。 ただし ftp: URI scheme の仕様は未だにいにしえの RFC 1738 のままで、実装とまったく整合していません。)

歴史

[126] http: は、最古の URL scheme の一つで、 WWW と共に誕生しました。

太古の定義

[97] HTTPAddressing -- /Addressing ( 版) http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Addressing/HTTPAddressing.html

RFC 1630 の定義

[96] RFC 1630 - Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web http://tools.ietf.org/html/rfc1630#page-13

RFC 1738 の定義

[95] RFC 1738 - Uniform Resource Locators (URL) http://tools.ietf.org/html/rfc1738#section-3.3

RFC 1808 の定義

[116] RFC 1808 - Relative Uniform Resource Locators ( 版) http://tools.ietf.org/html/rfc1808#section-2.3

[117] RFC 1808 は、「Note」の中で、 RFC 1738http: URL の中で普通に ; を認めていたけどその意味は明記しておらず、 RFC 1808 ではそれをちゃんと定義してる、と述べています。その意味というのがどういうことなのか実は不明確ですがw、 URI の一般的な構文における params のための区切子として扱われているので、 その意味で扱うべきという見解だったのでしょう。

RFC 1945、RFC 2068 の定義

[2] http: URLHTTP/1.0HTTP/1.1 の仕様の一部として RFC 1945 3.2 >>90RFC 2068 3.2 で規定されました。

[88] この仕様は当時の URL の正式な規定であるところの RFC 1738RFC 1808意図的違反していました。具体的には、本来 URL では使えないはずの nationalオクテット (つまり任意のオクテット) が認められていたりしました。 その理由としては、文字の制約に縛られていないこと、 はどのみち受け入れるしかないことが挙げられていました。

[91] 誤り処理であるとも取れますが、曖昧ですな。

[89] なんかこの ABNF 構文破綻してる気がしますが。。。 例えば segment = 2068.segment - "/" と定義しておかないと欲張り過ぎるんじゃ?

仕様書

RFC 2616 の定義

[85] RFC 2068 の改訂である RFC 2616 では、 national を認めていた独自の定義は削除され、 RFC 2396 に定義を委ねる形になっています。

[86]

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

RFC 2817

[118] RFC 2817 は、 Upgrade: による TLS/1.0 への切り替えを使う場合にも http: URL (https: でなく。) を使うことを提案していました。

[119] 実際にはこれは利用されておらず、 Upgrade: を使わない https: がもっぱら利用されています。
8.1 Implications for the https: URI Scheme

While nothing in this memo affects the definition of the 'https' URI scheme, widespread adoption of this mechanism for HyperText content could use 'http' to identify both secure and non-secure resources.

The choice of what security characteristics are required on the connection is left to the client and server. This allows either party to use any information available in making this determination. For example, user agents may rely on user preference settings or information about the security of the network such as 'TLS required on all POST operations not on my local net', or servers may apply resource access rules such as 'the FORM on this page must be served and submitted using TLS'.

RFC 2818

[44] RFC 2818 (HTTPS) では、 http: のかわりに https:URL scheme として使う >>123 と規定がありました。

[45] https: URL schemeSSL/2.0 以来使われていましたが、仕様書として明文化されたのはこの時が初めてと思われます。

Semantic Web 界での解釈

[5] What do HTTP URIs Identify? - Design Issues http://www.w3.org/DesignIssues/HTTP-URI (名無しさん)

[6] What do HTTP URIs Identify? - Design Issues http://www.w3.org/DesignIssues/HTTP-URI2.html (名無しさん)

[7] TAG Issues List http://www.w3.org/2001/tag/issues.html?type=1#httpRange-14 (名無しさん)

[8] URNs, Namespaces and Registries (2006-09-01 17:51:46 +09:00 版) http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html

RFC 5785

[42] RFC 5785/.well-known/ を定義しており、そのために http:RFC 2616https:RFC 2818更新しています。

RFC 7230

[446] HTTP の改訂版である RFC 7230 は、従来 RFC 2616 で定義されていた http: に加えて、 HTTPSRFC である RFC 2818 に含まれていた https: をも定義しています。

[448] RFC 3986 に基づく定義となっています。

[449] RFC 3987URL Standard は参照していません。

[447] IANA登録簿の登録も、更新されています >>445

[43] なお RFC 2616RFC 2818更新している RFC 5785更新するか、少なくても参照はしないと筋が通らなそうですが、 RFC 7230 は何も言及していません。

テスト・ケース

[1] Another HTML-lint : Explanation http://openlab.ring.gr.jp/k16/htmllint/explain.html#illegal-format-url 正しくない URI の例が幾つかあります。

関連

[16] http:/https: に非常によく似た URL scheme として、 SHTTP を表す shttp: があります。

[17] Web掲示板などでは、 http: URL を検知して自動的にハイパーリンクとして解釈する機能が適用されることを防ぐため、 ttp:tp:p: といった URL scheme を用いたり、 URL scheme を省略して : から始めたり、 「http」の一部又は全部を全角で表記したりすることがあります。

[13] HTTPにおけるURLの項もご覧ください。

メモ

[124] IRC logs: freenode / #whatwg / 20110808 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110808#l-1235

[22] Docker は次のような URL を使っているようです: http:///var/run/docker.sock/v1.15/images/create?fromImage=hoge%3Alatest

[46] Module ngx_http_proxy_module ( 版) http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

or as a UNIX-domain socket path specified after the word “unix” and enclosed in colons:

proxy_pass http://unix:/tmp/backend.socket:/uri/;

[53] ( 版) http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.01.01_60/ts_103285v010101p.pdf

HTTP-URL: URL with a fixed scheme of "http" or "https"

[64] Fix #244: improve HSTS language · whatwg/fetch@6568ab8 ( 版) https://github.com/whatwg/fetch/commit/6568ab88c1fbfb581f63f8e5f020c367ef38e78d

[65] Define HTTP(S) scheme for HTML ( (annevk著, )) https://github.com/whatwg/url/commit/08f9d3924f64cecf04746c926ac05c2429c5fe87

[68] Use URL's HTTP(S) scheme concept and define rel=icon better ( (annevk著, )) https://github.com/whatwg/html/commit/a932f7dfd5e50101db47a373cee27b04ed108934

[69] HTTPS and the Semantic Web/Linked Data | W3C Blog ( ()) https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/

[70] Editorial: use network and HTTP(S) scheme concepts ( (annevk著, )) https://github.com/whatwg/fetch/commit/a7e7af28629938544d1b705225d04776261a2ff4

[71] Non-HTTP(S) schemes are a network error during redirects ( (annevk著, )) https://github.com/whatwg/fetch/commit/9b75908a1e6f6f520a77b8b420015a61fb5d8512

[63] Editorial: move some terminology from the URL Standard here (annevk著, ) https://github.com/whatwg/fetch/commit/1d76b020ef8e90d1a021c70202060f8b27c29cd9

[72] Editorial: some terminology moved from the URL to Fetch Standard (annevk著, ) https://github.com/whatwg/html/commit/1308ec083b999df9ead67a2066e7e260fefae0e8

[73] Editorial: move some terminology to the Fetch Standard (annevk著, ) https://github.com/whatwg/url/commit/8fb8684a19b449db4c8920aee6cd3efb41bcdcfd

[77] Session URL :: WinSCP ( ()) https://winscp.net/eng/docs/session_url

sftp|ftp|ftps|ftpes|http|https|scp :// [ <username> [ : <password> ] [ ; <fingerprint> ] @ ] <host> [ : <port> ] /

[84] well-known-locations · Microformats Wiki () http://microformats.org/wiki/well-known-locations

[109] Module ngx_http_core_module () http://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes

[137] BitBake User Manual () http://www.yoctoproject.org/docs/2.4/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher

The fetcher supports a parameter "downloadfilename" that allows the name of the downloaded file to be specified. Specifying the name of the downloaded file is useful for avoiding collisions in DL_DIR when dealing with multiple files that have the same name.

[138] Chromium Blog: A secure web is here to stay () https://blog.chromium.org/2018/02/a-secure-web-is-here-to-stay.html

Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.

[140] RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push () https://tools.ietf.org/html/rfc8292#section-2.1

[141] RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push () https://tools.ietf.org/html/rfc8292#section-2.1

[142] 長谷みこと@ジェムカンさんはTwitterを使っています 「少し遅くなりましたが! #ミューコミプラス 出演させていただきありがとうございました! GEMSCOMPANYからよっぴーさんプロデュースユニット、Http: がもっと沢山の人に愛されるよう!ころん❤︎ #えいちてぃーてぃーぴーころん #ネットのかみさま #GEMSCOMPANY https://t.co/pEZAgwWXvb」 / Twitter () https://twitter.com/hasemikoto/status/1239451171154055173

[143] Skypeで特定の文字列を送受信するとクラッシュするバグが見つかり、修正版が公開される | スラド IT, https://it.srad.jp/story/15/06/05/226230/