[22] ftp: は、 FTP によってアクセス可能な資源を表す
URL です。
[23] ftp: URL scheme は現在公式には仕様書が存在しない状態です。
[64] ftp: URL は FTP の USER,
PASS, CWD, TYPE, NLST,
RETR といった命令の連続によってアクセス可能な資源を表しています。
[65] ftp: URL は階層的であり、
userinfo (user, password),
host, port,
path, fragment を使うことができます。
[24] userinfo に FTP でアクセスするための利用者名と合言葉を指定できます。
>>7, >>9 3.2.1. これは USER, PASS 両命令で使います。
>>9 3.2.1.
[25] 省略された場合の既定値は、匿名FTP の慣習により、利用者名
anonymous、合言葉が電子メール・アドレスとなります。
>>7, >>9 3.2.1.
[91] User@ などの実装依存の値が使われているようです。
WebブラウザーのFTPの動作を参照。
[39] この電子メール・アドレスは可能であれば実際に利用者が使えるアドレスとするべきであり、 クライアントの IPアドレスに解決されるような DNS ホスト名であることが好ましいとされていました。 >>7
[38] この要件は RFC 1738 で削除されています。
[92] 電子メールアドレスを指定するとの慣習は、90年代末には崩壊していました。 プライバシー保護のため、実装は勝手に利用者の電子メールアドレスを送信するべきではありません。
[40] 利用者名だけしか指定されていない場合で鯖が合言葉を要求してきた場合は、 利用者に尋ねるべきです。 >>9 3.2.1.
[42] ftp: URL の path 部分は次のような構文となります。
>>9 3.2.
/<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
[43] これ全体が省略可能です。 >>9 3.2.2.
省略された場合、URLの正準化により、 / が指定されたとみなされます。
[44] cwd や name は空文字列であっても構いません。 >>9 3.2.2.
[45] ;type=... は省略可能です。 >>7, >>9 3.2.2., >>9 3.2.3.
[93] 先頭の / の直後から ; の直前までの部分が、実際に FTP
で用いられるパスとして扱われます。このパス全体について、
一度で RETR や CWD が行われます。
[95] ただし、非ASCII文字はURLの正準化により UTF-8 で符号化されますし、
パーセント符号化は復号し、バイト列を得て、
それをパスとして使います。元の URL に %2F が含まれていると、
URL としては / とは違いますが (例えば相対URLの解決に影響します)、
FTP レベルでは / と指定したのと同じことになります。
[94] しかしかつては違った規定や実装のされ方もありました。
[46] path は、 FTP によるアクセスにおいて、まず cwd
によって表される CWD 命令を発行し、次に
typecode によって表される TYPE 命令を発行し、
最後に name によって表される RETR
命令を発行することを意味しています。
[67] なお、 RFC 1738 の構文定義では path 内で ?
を使うことができるとされていましたが、これは誤りであったと考えられており、
RFC 1808 で訂正されています。 >>12 2.3.
[26] cwd の部分は、それぞれについて CWD
命令を発行して作業ディレクトリーを変更することを表しています。
>>7, >>9 3.2.2.
[27] Unix では / をディレクトリーの区切りに使うので、
FTP の URL と FTP の背後のファイル・システム上のディレクトリーが同じになることがあります。
ただし FTP を Unix ファイル・システムにより実装しなければならないわけではありません。
>>7, >>9 3.2.4.
[28] FTP 仕様上は FTP における階層化について共通のモデルが無く、 同じホストの FTP アクセスを連続して行う時に意図したディレクトリーへと確実に移動する方法がありません。 2つの同じホストの FTP URL へのアクセスを意図通り確実に行う方法は、 一旦接続を切断して再接続するというものだけです。 >>7, >>9 3.2.5.
[47] cwd は空文字列となることがありますが、これは空文字列を与えて
CWD 命令を送信するということのよう >>9 3.2.2. です。
[1] frp://foo.example/bar という URI
に基づいて FTP で foo.example
に接続した時、 RFC 1738 に従えば CWD bar
を送る必要がありますが、多くの UA
は CWD /bar とします。
このため、 frp://foo.example/~bar
で、利用者 bar の HOME を示しているものを正しく動作させるためには最初の文字が ~
である時だけ特別扱いしないといけません。
なお、 Lynx は RFC 1738 に触れながらも、現実の実装にあわせて敢えて 「間違った」やり方にしていると言っています。
RFC 1738 の方法に従うと、 FTP で接続した直後の current directory によって URI の指すものが変わってくる虞があります。
(参考 w3m-dev #3787)
[2]
>>1 のような事情で、 ftp://user@foo.example/ だと root directory になるが、 ftp://user@foo.example/./ だと ~ になるという裏技(?)があるらしい。
[71]
2004年の I-D (>>19) は、「ほとんどの実装は最初に / をつける」
としながらも、 RFC 1738 と同じ定義を採用し、「鯖の実装者は二つの解釈があるので注意せよ」
と述べるにとどまっています >>19 2.2。
[48] name の部分は RETR 命令により取得するファイル名を表します。
[49] RFC 1630 では name が空文字列の時には NLST
命令によりディレクトリー内のファイルの一覧を取得することを表すとされていました
>>7 が、 RFC 1738 ではそうは説明されていません。
代わりにどのような意味を表すのかは明確ではありませんが、
空文字列を引数として RETR 命令を送信するということで良いのでしょうか・・・。
[60] cwd と name はパーセント符号化を使えます。 FTP の命令に使う前にパーセント復号しなければなりません >>9 3.2.2.。
[61] cwd と name において / と
; は予約されており、命令の引数として使うことを意図しているのであればパーセント符号化しなければなりません。
>>9 3.2.2.
type[29] path の最後には TYPE 命令によって指定するデータ型を付加できます。
>>7, >>9 3.2.2.
[32] ASCII テキスト、バイナリーといった FTP の転送時のデータ型は、
CWD 命令と RETR 命令の間に
TYPE 命令を送信することによって指定します。
>>7, >>9 3.2.2.
[51] このデータ型を決定する方法は一般には存在しません。 type
が指定されている場合は、それを利用します。そうでない場合は、ファイル名の接尾辞
(拡張子) などから推定しなければなりません。ただしそれについて標準化された方法はありません。
>>7, >>9 3.2.2.
[53] ただし、値が d の場合、 TYPE と RETR
の代わりに NLST 命令を送信して、ディレクトリー内のファイルの一覧を取得します。
>>9 3.2.2.
[52] 「type」の部分は RFC 1630 の構文定義上は小文字でなければならないように読めます。
RFC 1738 では ABNF 構文定義上大文字でも小文字でも構わないと解釈するのが形式的には正しいのでしょうが、
値の生成規則ではあえて大文字と小文字を列挙しているので、小文字だけしか認めないという意図があるかもしれません。
[34] RFC 1630 の構文定義上は値は大文字でなければならないように読めますが、 RFC 1738 には小文字で示されており、 現実にも小文字でも構わないようです。 RFC 1738 の ABNF 構文定義上は両方共認められています。
[69] 前述の通り、ディレクトリーを表す URL としては RFC 1630
による path を / で終わらせる方法と、 RFC 1738
による ;type=d で終わらせる方法が存在しています。
[70] この両者は、相対URL の解決において解釈を変えてしまいます。
そのため、 RFC 1808 は相対URL を扱う文脈にあっては ;type=d
の方法を使わないことを推奨しています >>12 5.3.。
[89] Chrome は raw が指定されていると、ディレクトリー内表示を整形した
HTML ではなく、サーバーから送られてきたテキストデータのままで表示します。
sniffing も行いません。ディレクトリー以外では無視します。
[8] IETF として最初の URI の仕様書である RFC 1630 には、 ftp:
URL の仕様も含まれていました。
[7] 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-14
ftpaddress f t p : / / login / path [ ftptype ] login [ user [ : password ] @ ] hostport ftptype A formcode | E formcode | I | L digits formcode N | T | C
[10] IETF 標準化過程としては最初の URL の仕様書である RFC 1738 にも、
ftp: URL の仕様が含まれていました。
[9] RFC 1738 - Uniform Resource Locators (URL) http://tools.ietf.org/html/rfc1738#section-3.2
[62] 構文は次のように定義されていました >>9 5.。
; FTP (see also RFC959) ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]] fpath = fsegment *[ "/" fsegment ] fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ] ftptype = "A" | "I" | "D" | "a" | "i" | "d"
[11] IETF 標準化過程としては最初の相対URL の仕様書である RFC 1808 には、
ftp: URL に関する相対URL の扱いについての規定も含まれていました。
[12] RFC 1808 - Relative Uniform Resource Locators http://tools.ietf.org/html/rfc1808
[16] RFC 1738, RFC 1808 はその後 RFC 2368 (1998年), RFC 3986
(2005年) と二度も改訂され、
ftp: を含む個別の URL scheme の定義は含まれないようになりましたが、
ftp: の定義は独立した RFC にならないまま RFC 1738,
RFC 1808 ともに廃止されてしまいました。
[17] 現実には ftp: は URL scheme の中ではよく使われている部類なのですが、
数年以上公式には廃止された状態が続くとか、 IETF の標準化過程は無茶苦茶ですね。
[18] 一応 I-D はありますが、果たして完成するのかどうか。
[75] draft-casey-url-ftp-00 - A FTP URL Format http://tools.ietf.org/html/draft-casey-url-ftp-00
[76] この I-D は基本的には RFC 1738 の定義を踏襲していますが、 >>1 の件を既知の問題として記述しています。
[19] draft-hoffman-ftp-uri-04 - The ftp URI Scheme http://tools.ietf.org/html/draft-hoffman-ftp-uri-04
[73] この2004年の I-D は RFC 1738 の該当部分を抜き出しただけで、唯一の違いは >>71 です。 ABNF 構文定義はコピペされていないので、構文は本文中で曖昧に述べられているだけです。 仕事が雑ですねぇ。
[6] Web Forms 2.0 ではじめて ftp: URL へのフォーム提出の処理モデルが規定されました。
これはその後 Web Applications 1.0 に取り込まれました。
[3] Web Forms 2.0 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#for-ftp
ftp://ftp.is.co.za/rfc/rfc1808.txt
ftp://user@example.com:/pub/ruby;type=i
ftp://myname@host.dom/%2Fetc/motd
CWD /etc を実行し、RETR motd を実行します。 >>9 3.2.2.ftp://myname@host.dom/etc/motd
CWD etc を実行し、RETR motd を実行します。 >>9 3.2.2.ftp://myname@host.dom//etc/motd
CWD を実行し、CWD etc を実行し、RETR motd を実行します。 >>9 3.2.2.ftp://host/~/foo/bar.html ftp://user:pass@host/~/
>>1 の問題への対処として、実際の Webブラウザーの挙動に従うとして、 ホーム・ディレクトリーからの path でアクセスする方法が必要であると提案されていた >>71 構文です。
[20] ftp: と file: はしばしば混同されますが、別物です。
[21] sftp:、tftp: という URL scheme がありますが、そもそも
FTP と SFTP や TFTP は別物です。
[74] Results for ftp: URL canonicalization (See https://suika.suikawiki.org/www/url/perl-weburl/t/browsers/decomps.html?decomps-ftp.dat;compat) ( ( 版)) https://suika.suikawiki.org/gate/test-results/list/url-canon-ftp-20110604/all
[78] URL Schemes Supported in Lynx ( ( 版)) http://lynx.isc.org/current/lynx2-8-8/lynx_help/lynx_url_support.html#ncftp_url
[79] ncsa-mosaic/CHANGES at master · alandipert/ncsa-mosaic ( ( 版)) https://github.com/alandipert/ncsa-mosaic/blob/master/CHANGES#L189
[80] FTP URLs ( ( 版)) https://www.cs.tut.fi/~jkorpela/ftpurl.html
An FTP URI is interpreted relative to the home directory of the user who is logging in. Alas, to reach higher directory levels you cannot use /../, as the dots are interpreted by the browser and not actually sent to the FTP server. To address this problem, the so called Squid %2f hack was implemented in the Apache FTP proxy; it is a solution which is also used by other popular proxy servers like the Squid Proxy Cache. By prepending /%2f to the path of your request, you can make such a proxy change the FTP starting directory to / (instead of the home directory). For example, to retrieve the file /etc/motd, you would use the URL:
ftp://user@host/%2f/etc/motd
Note: For FTP URLs, it is legal to specify a user name and password in the URL as follows:
ftp://myname:mypassword@myhost.mydomain.com/foo.dat
This is highly discouraged as you will be sending your username and password in plain text over the network. For servers provided in the Globus Toolkit, username and password is not a permitted authentication method and so this format will result in an error (??? what error ???). The exception to this is anonymous FTP access (how does this work in globus-url-copy).
FTP
ftp[s]://user[:password]@other.host[:port]/some_dir
NOTE: use lftp+, ncftp+ prefixes to enforce a specific backend, e.g. ncftp+ftp://...
[82] The FTP Content Provider (Kai Sommerfeld 著, 版) https://www.openoffice.org/ucb/docs/ucp-ref/ftp-ucp.html
<td width="2%">
<center><a href="http://ring.u-toyama.ac.jp/index.html.ja"><img src="ring/images/U-toyamaLogo.png" alt="" height="64" width="64"><br>富山大学</a></center>
<center>
<a href="http://ring.u-toyama.ac.jp/archives/">HTTP</a><br><a href="ftp://ring.u-toyama.ac.jp/pub/">FTP</a><br>
</center>
</td>
<ul>
<li>HTTP: <a href="http://www.iana.org/time-zones">http://www.iana.org/time-zones</a></li>
<li>FTP: <a href="ftp://ftp.iana.org/tz/">ftp://ftp.iana.org/tz/</a></li>
<li>Rsync: <a href="rsync://rsync.iana.org/tz/">rsync://rsync.iana.org/tz/</a></li>
</ul>
-B, --use-ascii
(FTP/LDAP) Enable ASCII transfer. For FTP, this can also be enforced by using an URL that ends with ";type=A". This option causes data sent to stdout to be in text mode for win32 systems.
[86] 207298 – FTP directory problems w/ URL parsing when URL root is not filesystem root ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=207298
[87] 202419 – ftp://@hostname should tell FTP to use username and password auth ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=202419
[98] Intent to deprecate: Legacy subresource requests. - Google グループ () https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/bAMVnc1Zyvs
[99] 333943 - Remove built-in support for FTP from Chrome - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=333943
[100] Block ftp URL requests from non-FTP clients (mikewest著, ) https://github.com/whatwg/fetch/commit/d4114a3b0926fda64a7708d4ec56c6d007b5d133
sftp|ftp|ftps|ftpes|http|https|scp :// [ <username> [ : <password> ] [ ; <fingerprint> ] @ ] <host> [ : <port> ] /
[103] PSA: `ftp://` resources will be marked "Not Secure" - Google グループ () https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/HknIAQwMoWo/xYyezYV5AAAJ
[104] 744499 - Consider downloading `ftp://` resources rather than rendering them. - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=744499
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.
[106] 435547 - Evaluate dropping legacy and credentialed subresource requests. - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=435547
[107] 1404744 - Block ftp subresource requests inside http(s) pages () https://bugzilla.mozilla.org/show_bug.cgi?id=1404744
[108] 1361848 - ftp allows bypassing cross site authentication (XSA) warning on login forms () https://bugzilla.mozilla.org/show_bug.cgi?id=1361848
[109] Intent to implement and ship: Blocking FTP subresources - Google グループ () https://groups.google.com/forum/#!topic/mozilla.dev.platform/HzumeW2JQW8
[110] Consider a blocklist for schemes instead of a safelist · Issue #3998 · whatwg/html () https://github.com/whatwg/html/issues/3998
[111] Blocking FTP subresource loads within non-FTP documents in Firefox 61 | Mozilla Security Blog () https://blog.mozilla.org/security/2018/05/07/blocking-ftp-subresource-loads-within-non-ftp-documents-in-firefox-61/
[112] No longer render resources requested via FTP (mikewest著, ) https://github.com/whatwg/fetch/commit/c6b3a750f811cb4f628def0313ac317d9dcec88a
[113] Consider downloading rather than rendering resources delivered over FTP. · Issue #4178 · whatwg/html () https://github.com/whatwg/html/issues/4178
[114] Treat resources requested via FTP as binary data. by mikewest · Pull Request #839 · whatwg/fetch () https://github.com/whatwg/fetch/pull/839
[115] Deprecate FTP support - Chrome Platform Status () https://chromestatus.com/feature/6246151319715840