[22] ftp: は、 FTP によってアクセス可能な資源を表す URL です。

仕様書

[23] ftp: URL scheme は現在公式には仕様書が存在しない状態です。

意味

[64] ftp: URL は FTP の USER, PASS, CWD, TYPE, NLST, RETR といった命令の連続によってアクセス可能な資源を表しています。

[36] RFC 1630 では FTP の転送モードとしては常にストリーム・モードを使うことを表している >>7 とされていました。この規定は RFC 1738 で削除されています。

構文

[65] ftp: URL は階層的であり、 userinfo (user, password), host, port, path, fragment を使うことができます。

[88] Chrome は queryURL query も一部使っています。

[66] 相対URL を使うこともできます。

userinfo

[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.

[41] 現実にはどちらも指定されていない場合であっても、必要なら利用者に問い合わせるのが一般的な気がします。

port

[37] FTP の既定のポート番号は 21 です >>9 3.2.。

path

[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。

[72] のんきなものですね。標準化は何のためにやるものなんだか。

ファイル名部分

[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.

[63] type とその値について、 RFC 1738 の ABNF 構文上パーセント符号化は認められていません。

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.

[54] これは RFC 1630 にはありませんでした。

[52] 「type」の部分は RFC 1630 の構文定義上は小文字でなければならないように読めます。 RFC 1738 では ABNF 構文定義上大文字でも小文字でも構わないと解釈するのが形式的には正しいのでしょうが、 値の生成規則ではあえて大文字と小文字を列挙しているので、小文字だけしか認めないという意図があるかもしれません。

[34] RFC 1630 の構文定義上は値は大文字でなければならないように読めますが、 RFC 1738 には小文字で示されており、 現実にも小文字でも構わないようです。 RFC 1738 の ABNF 構文定義上は両方共認められています。

[68] ; 以後の部分は RFC 1808 までは引数 (params) として path とは別の構成部品と考えられていました。 RFC 2396 以後は path の一部とみなされています。

ディレクトリーの表現

[69] 前述の通り、ディレクトリーを表す URL としては RFC 1630 による path を / で終わらせる方法と、 RFC 1738 による ;type=d で終わらせる方法が存在しています。

[70] この両者は、相対URL の解決において解釈を変えてしまいます。 そのため、 RFC 1808 は相対URL を扱う文脈にあっては ;type=d の方法を使わないことを推奨しています >>12 5.3.。

query

[89] Chrome は raw が指定されていると、ディレクトリー内表示を整形した HTML ではなく、サーバーから送られてきたテキストデータのままで表示します。 sniffing も行いません。ディレクトリー以外では無視します。

[90] 他の Webブラウザーは queryURL query があっても無視します。

処理

fetch

[96] WebブラウザーのFTPの動作参照。

[58] RETR によってファイルを取得したり、 NLST によってディレクトリー内のファイルの一覧を取得したりする操作は、 ftp: URL の定義として概ね明確に規定されています。

[59] それ以外の、アップロードや情報の取得などの操作に ftp: URL を使うことについては述べない >>9 3.2.2. とされています。

フォーム提出

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

  • [5] Web Applications 1.0 ( 版) http://www.whatwg.org/specs/web-apps/current-work/complete.html#form-submission-algorithm

歴史

RFC 1630

[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

1994年

[35] 構文は次のように定義されていました >>7。

  ftpaddress             f t p : / / login / path [  ftptype ]
  login                  [ user [ : password ] @ ] hostport
  ftptype                A formcode | E formcode | I | L digits
  formcode               N | T | C
[33] ftptype の定義が間違っています。なお、 / で終わるディレクトリー指定の場合は path の定義に含まれています。

RFC 1738

[10] IETF 標準化過程としては最初の URL の仕様書である RFC 1738 にも、 ftp: URL の仕様が含まれていました。

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

1994年

[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"

RFC 1808

[11] IETF 標準化過程としては最初の相対URL の仕様書である RFC 1808 には、 ftp: URL に関する相対URL の扱いについての規定も含まれていました。

[12] RFC 1808 - Relative Uniform Resource Locators http://tools.ietf.org/html/rfc1808

1995年

RFC 改訂、されない

[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 はありますが、果たして完成するのかどうか。

draft-casey-url-ftp (1997)

[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 の件を既知の問題として記述しています。

draft-hoffman-ftp-uri (2004-2005)

[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 構文定義はコピペされていないので、構文は本文中で曖昧に述べられているだけです。 仕事が雑ですねぇ。

draft-yevstifeyev-ftp-uri-scheme (2011)

  • [102] draft-yevstifeyev-ftp-iri-00 - Internalization of 'ftp' URIs () https://tools.ietf.org/html/draft-yevstifeyev-ftp-iri-00
  • [15] draft-yevstifeyev-ftp-uri-scheme - The 'ftp' URI Scheme https://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme

フォーム提出

[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

例

[13] 

ftp://ftp.is.co.za/rfc/rfc1808.txt

[14]

ftp://user@example.com:/pub/ruby;type=i

この URL を書いた人の意図とは違うような気もしますが、たまたま正しい URL です。

[55] 

ftp://myname@host.dom/%2Fetc/motd

  1. host.dom に FTP で接続して
  2. 利用者名 myname (と、聞かれれば利用者に尋ねた合言葉) でログインし、
  3. CWD /etc を実行し、
  4. RETR motd を実行します。 >>9 3.2.2.

[56] 

ftp://myname@host.dom/etc/motd

  1. host.dom に FTP で接続して
  2. 利用者名 myname (と、聞かれれば利用者に尋ねた合言葉) でログインし、
  3. CWD etc を実行し、
  4. RETR motd を実行します。 >>9 3.2.2.

[57] 

ftp://myname@host.dom//etc/motd

  1. host.dom に FTP で接続して
  2. 利用者名 myname (と、聞かれれば利用者に尋ねた合言葉) でログインし、
  3. CWD を実行し、
  4. CWD etc を実行し、
  5. RETR motd を実行します。 >>9 3.2.2.

[77] 

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

[4] mod_proxy_ftp - Apache HTTP Server Version 2.4 ( 版) http://httpd.apache.org/docs/current/en/mod/mod_proxy_ftp.html#percent2fhck

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

[30] GridFTP: User's Guide ( 版) http://toolkit.globus.org/toolkit/docs/3.2/gridftp/user/globusurlcopy.html

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).

[81] DUPLICITY(1) manual page ( 版) http://duplicity.nongnu.org/duplicity.1.html#sect7

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

[83] ( 版) http://www.ring.gr.jp/

<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>

[84] ( 版) https://www.iana.org/time-zones

<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>

[85] cURL - How To Use ( ()) https://curl.haxx.se/docs/manpage.html#-B

-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

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

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

[105] 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.

[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