rio 0.4.2 → 0.5.1
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +21 -0
- data/Gemfile +4 -0
- data/{COPYING → LICENSE} +3 -0
- data/README +20 -27
- data/Rakefile +48 -277
- data/lib/rio.rb +63 -24
- data/lib/rio/.document +5 -0
- data/lib/rio/abstract_method.rb +3 -14
- data/lib/rio/alturi.rb +507 -0
- data/lib/rio/alturi/algorithm.rb +313 -0
- data/lib/rio/alturi/cached_fields.rb +68 -0
- data/lib/rio/alturi/escape.rb +82 -0
- data/lib/rio/alturi/parse.rb +75 -0
- data/lib/rio/alturi/path_parts.rb +81 -0
- data/lib/rio/alturi/regex.rb +76 -0
- data/lib/rio/alturi/uri_parts.rb +512 -0
- data/lib/rio/argv.rb +3 -14
- data/lib/rio/arraynge.rb +146 -0
- data/lib/rio/arycopy.rb +3 -14
- data/lib/rio/assert.rb +87 -15
- data/lib/rio/base.rb +7 -30
- data/lib/rio/callstr.rb +3 -14
- data/lib/rio/const.rb +3 -14
- data/lib/rio/construct.rb +4 -15
- data/lib/rio/constructor.rb +4 -19
- data/lib/rio/context.rb +17 -14
- data/lib/rio/context/autoclose.rb +3 -14
- data/lib/rio/context/binmode.rb +63 -0
- data/lib/rio/context/copying.rb +3 -14
- data/lib/rio/context/cxx.rb +3 -14
- data/lib/rio/context/dir.rb +5 -15
- data/lib/rio/context/encoding.rb +84 -0
- data/lib/rio/context/gzip.rb +3 -14
- data/lib/rio/context/methods.rb +8 -17
- data/lib/rio/context/skip.rb +3 -14
- data/lib/rio/context/stream.rb +3 -14
- data/lib/rio/cp.rb +5 -20
- data/lib/rio/cxuri.rb +67 -0
- data/lib/rio/dbg/trace_states.rb +18 -0
- data/lib/rio/def.rb +3 -14
- data/lib/rio/dir.rb +9 -18
- data/lib/rio/doc.rb +3 -14
- data/lib/rio/doc/EXAMPLES.rb +256 -269
- data/lib/rio/doc/HOWTO.rb +685 -707
- data/lib/rio/doc/INDEX.rb +261 -282
- data/lib/rio/doc/INTRO.rb +1029 -1040
- data/lib/rio/doc/OPTIONAL.rb +77 -103
- data/lib/rio/doc/SYNOPSIS.rb +122 -143
- data/lib/rio/entrysel.rb +3 -14
- data/lib/rio/exception.rb +4 -14
- data/lib/rio/exception/copy.rb +3 -14
- data/lib/rio/exception/notimplemented.rb +3 -14
- data/lib/rio/exception/notsupported.rb +3 -14
- data/lib/rio/exception/open.rb +3 -14
- data/lib/rio/exception/state.rb +3 -14
- data/lib/rio/ext.rb +14 -17
- data/lib/rio/ext/csv.rb +25 -304
- data/lib/rio/ext/csv/csv-legacy.rb +344 -0
- data/lib/rio/ext/csv/csv.rb +359 -0
- data/lib/rio/ext/csv/filter.rb +209 -0
- data/lib/rio/ext/if.rb +3 -14
- data/lib/rio/ext/mp3info.rb +3 -14
- data/lib/rio/ext/splitlines.rb +3 -14
- data/lib/rio/ext/yaml.rb +3 -14
- data/lib/rio/ext/yaml/doc.rb +3 -14
- data/lib/rio/ext/yaml/tie.rb +3 -14
- data/lib/rio/ext/zipfile.rb +3 -14
- data/lib/rio/ext/zipfile/fs.rb +3 -14
- data/lib/rio/ext/zipfile/rl.rb +3 -14
- data/lib/rio/ext/zipfile/rootdir.rb +3 -14
- data/lib/rio/ext/zipfile/state.rb +3 -14
- data/lib/rio/ext/zipfile/wrap.rb +3 -14
- data/lib/rio/factory.rb +96 -213
- data/lib/rio/fibpipe.rb +373 -0
- data/lib/rio/file.rb +8 -17
- data/lib/rio/filter.rb +4 -15
- data/lib/rio/filter/closeoneof.rb +3 -14
- data/lib/rio/filter/gzip.rb +18 -27
- data/lib/rio/fs.rb +172 -0
- data/lib/rio/fs/base.rb +3 -14
- data/lib/rio/fs/impl.rb +3 -14
- data/lib/rio/fs/native.rb +3 -14
- data/lib/rio/fs/stream.rb +3 -14
- data/lib/rio/fs/url.rb +3 -14
- data/lib/rio/ftp/conncache.rb +16 -18
- data/lib/rio/ftp/dir.rb +4 -15
- data/lib/rio/ftp/fs.rb +62 -42
- data/lib/rio/fwd.rb +15 -0
- data/lib/rio/grande.rb +4 -15
- data/lib/rio/handle.rb +3 -45
- data/lib/rio/if.rb +15 -20
- data/lib/rio/if/basic.rb +3 -36
- data/lib/rio/if/csv.rb +7 -20
- data/lib/rio/if/dir.rb +9 -21
- data/lib/rio/if/file.rb +6 -19
- data/lib/rio/if/fileordir.rb +18 -29
- data/lib/rio/if/grande.rb +109 -120
- data/lib/rio/if/grande_entry.rb +5 -18
- data/lib/rio/if/grande_stream.rb +29 -42
- data/lib/rio/if/internal.rb +15 -16
- data/lib/rio/if/path.rb +35 -47
- data/lib/rio/if/rubyio.rb +35 -47
- data/lib/rio/if/string.rb +3 -16
- data/lib/rio/if/temp.rb +3 -16
- data/lib/rio/if/test.rb +8 -20
- data/lib/rio/if/yaml.rb +16 -29
- data/lib/rio/ioh.rb +35 -34
- data/lib/rio/iomode.rb +3 -14
- data/lib/rio/ios/fail.rb +3 -14
- data/lib/rio/ios/generic.rb +3 -14
- data/lib/rio/ios/mode.rb +3 -14
- data/lib/rio/ios/null.rb +3 -14
- data/lib/rio/iowrap.rb +3 -14
- data/lib/rio/kernel.rb +4 -17
- data/lib/rio/local.rb +3 -14
- data/lib/rio/match.rb +3 -14
- data/lib/rio/matchrecord.rb +8 -17
- data/lib/rio/no_warn.rb +3 -14
- data/lib/rio/nullio.rb +3 -14
- data/lib/rio/open3.rb +3 -16
- data/lib/rio/ops.rb +33 -0
- data/lib/rio/ops/construct.rb +3 -14
- data/lib/rio/ops/create.rb +11 -25
- data/lib/rio/ops/dir.rb +17 -24
- data/lib/rio/ops/either.rb +28 -31
- data/lib/rio/ops/file.rb +29 -26
- data/lib/rio/ops/path.rb +65 -34
- data/lib/rio/ops/stream.rb +13 -15
- data/lib/rio/ops/stream/input.rb +59 -28
- data/lib/rio/ops/stream/output.rb +4 -14
- data/lib/rio/ops/stream/read.rb +4 -15
- data/lib/rio/ops/stream/write.rb +3 -14
- data/lib/rio/ops/symlink.rb +6 -15
- data/lib/rio/path.rb +10 -17
- data/lib/rio/path/reset.rb +3 -14
- data/lib/rio/piper.rb +3 -27
- data/lib/rio/piper/cp.rb +50 -27
- data/lib/rio/prompt.rb +3 -14
- data/lib/rio/rectype.rb +8 -16
- data/lib/rio/rl/base.rb +12 -25
- data/lib/rio/rl/builder.rb +25 -24
- data/lib/rio/rl/chmap.rb +3 -16
- data/lib/rio/rl/fs2url.rb +5 -16
- data/lib/rio/rl/ioi.rb +3 -14
- data/lib/rio/rl/path.rb +14 -25
- data/lib/rio/rl/pathmethods.rb +3 -14
- data/lib/rio/rl/uri.rb +18 -35
- data/lib/rio/rl/withpath.rb +36 -53
- data/lib/rio/rrl/base.rb +75 -0
- data/lib/rio/rrl/builder.rb +122 -0
- data/lib/rio/rrl/chmap.rb +53 -0
- data/lib/rio/rrl/ioi.rb +78 -0
- data/lib/rio/rrl/path.rb +117 -0
- data/lib/rio/rrl/withpath.rb +269 -0
- data/lib/rio/scheme/aryio.rb +3 -14
- data/lib/rio/scheme/cmdio.rb +73 -42
- data/lib/rio/scheme/cmdpipe.rb +122 -59
- data/lib/rio/scheme/fd.rb +19 -33
- data/lib/rio/scheme/ftp.rb +34 -40
- data/lib/rio/scheme/http.rb +13 -22
- data/lib/rio/scheme/null.rb +6 -17
- data/lib/rio/scheme/path.rb +60 -71
- data/lib/rio/scheme/stderr.rb +9 -21
- data/lib/rio/scheme/stdio.rb +14 -26
- data/lib/rio/scheme/strio.rb +37 -38
- data/lib/rio/scheme/sysio.rb +20 -32
- data/lib/rio/scheme/tcp.rb +3 -14
- data/lib/rio/scheme/temp.rb +103 -92
- data/lib/rio/state.rb +85 -67
- data/lib/rio/state/data.rb +55 -0
- data/lib/rio/state/error.rb +7 -27
- data/lib/rio/stream.rb +46 -19
- data/lib/rio/stream/base.rb +14 -14
- data/lib/rio/stream/duplex.rb +64 -26
- data/lib/rio/stream/open.rb +9 -19
- data/lib/rio/symantics.rb +3 -14
- data/lib/rio/tempdir.rb +8 -17
- data/lib/rio/to_rio.rb +3 -16
- data/lib/rio/to_rio/all.rb +3 -14
- data/lib/rio/to_rio/array.rb +3 -14
- data/lib/rio/to_rio/io.rb +3 -14
- data/lib/rio/to_rio/object.rb +3 -14
- data/lib/rio/to_rio/string.rb +3 -14
- data/lib/rio/uri/file.rb +98 -153
- data/lib/rio/uriref.rb +144 -0
- data/lib/rio/util.rb +3 -14
- data/lib/rio/version.rb +4 -15
- data/misc/clean-heading-comments.rb +39 -0
- data/misc/fixdoclinks.rb +36 -0
- data/misc/update-copyright.rb +17 -0
- data/rio.gemspec +31 -0
- data/test/alturi/tc/create.rb +24 -0
- data/test/alturi/tc/empty.rb +13 -0
- data/test/alturi/tc/encoding.rb +73 -0
- data/test/alturi/tc/file_test.rb +335 -0
- data/test/alturi/tc/ftp_alturi.rb +147 -0
- data/test/alturi/tc/generic_test.rb +335 -0
- data/test/alturi/tc/http_test.rb +359 -0
- data/test/alturi/tc/path_parts_test.rb +215 -0
- data/test/alturi/tc/rfc_test.rb +83 -0
- data/test/alturi/tc/uri_parts_authority.rb +129 -0
- data/test/alturi/tc/uri_parts_test.rb +473 -0
- data/test/alturi/tc/uri_parts_userinfo.rb +140 -0
- data/test/alturi/tests.rb +27 -0
- data/test/base_test.rb +18 -0
- data/test/bin/demo_chdir.rb +60 -0
- data/test/bin/elipsis.rb +11 -0
- data/test/env.sh +4 -0
- data/test/ftp/initftpfiles.rb +1 -0
- data/test/ftp/tc/anon_copy_data.rb +31 -0
- data/test/ftp/tc/anon_misc.rb +109 -0
- data/test/ftp/tc/anon_read.rb +99 -0
- data/test/ftp/tc/anon_special.rb +37 -0
- data/test/ftp/tc/anon_write.rb +68 -0
- data/test/ftp/tc/copy.rb +35 -0
- data/test/ftp/tc/empty.rb +16 -0
- data/test/ftp/tc/ftp2ftp.rb +42 -0
- data/test/ftp/tc/ftp_fs.rb +333 -0
- data/test/ftp/testdef.rb +7 -2
- data/test/ftp/tests.rb +24 -0
- data/test/gem_runtests.rb +1 -1
- data/test/http/copy-from-http.rb +0 -1
- data/test/http/def.rb +20 -0
- data/test/http/tc/copy_from_http.rb +128 -0
- data/test/http/tc/empty.rb +14 -0
- data/test/http/tc/uri_meta.rb +52 -0
- data/test/http/tests.rb +19 -0
- data/test/lib/assertions.rb +7 -0
- data/test/lib/run_tests.rb +26 -0
- data/test/lib/temp_server.rb +7 -4
- data/test/methods/test_suite.rb +108 -0
- data/test/platform.rb +5 -0
- data/test/qpdir.rb +2 -0
- data/test/rio/scheme.rb +49 -0
- data/test/rio/tc/pathparts.rb +61 -0
- data/test/riotest/test_suite.rb +33 -0
- data/test/riotest/unit_test.rb +118 -0
- data/test/riotest/util.rb +23 -0
- data/test/runalltests.rb +1 -1
- data/test/runftptests.rb +2 -7
- data/test/runhttp.rb +4 -2
- data/test/runhttptests.rb +6 -5
- data/test/runtests.rb +66 -37
- data/test/srv/www/htdocs/riotest/dir/index.html +11 -0
- data/test/srv/www/htdocs/riotest/hw.html +8 -0
- data/test/srv/www/htdocs/riotest/lines.txt.gz +0 -0
- data/test/tc/abs2.rb +358 -0
- data/test/tc/all.rb +17 -10
- data/test/tc/base2.rb +8 -7
- data/test/tc/clearsel.rb +3 -2
- data/test/tc/closeoneof.rb +14 -15
- data/test/tc/cmdio.rb +193 -0
- data/test/tc/cmdpipe.rb +258 -63
- data/test/tc/copy.rb +3 -2
- data/test/tc/copyarray.rb +0 -4
- data/test/tc/copydest.rb +2 -3
- data/test/tc/copydir.rb +5 -1
- data/test/tc/copydir2.rb +68 -0
- data/test/tc/create.rb +4 -9
- data/test/tc/csv.rb +38 -119
- data/test/tc/csv2.rb +38 -57
- data/test/tc/csv_columns.rb +210 -8
- data/test/tc/csv_gzip.rb +78 -0
- data/test/tc/csv_headers.rb +134 -0
- data/test/tc/csvutil.rb +53 -16
- data/test/tc/dir.rb +3 -4
- data/test/tc/dir_iter.rb +3 -1
- data/test/tc/dirent.rb +8 -7
- data/test/tc/each.rb +62 -47
- data/test/tc/each_break.rb +67 -25
- data/test/tc/edf.rb +3 -2
- data/test/tc/empty.rb +6 -4
- data/test/tc/encoding.rb +30 -0
- data/test/tc/entary.rb +6 -5
- data/test/tc/eq.rb +2 -2
- data/test/tc/expand_path.rb +14 -14
- data/test/tc/ext.rb +7 -7
- data/test/tc/fileno.rb +3 -2
- data/test/tc/files_select.rb +1 -1
- data/test/tc/getrec.rb +2 -3
- data/test/tc/gzip.rb +5 -3
- data/test/tc/likeio.rb +5 -5
- data/test/tc/lineno.rb +1 -1
- data/test/tc/lines.rb +4 -4
- data/test/tc/misc.rb +29 -171
- data/test/tc/nolines.rb +4 -2
- data/test/tc/noqae.rb +12 -10
- data/test/tc/overload.rb +1 -2
- data/test/tc/pa.rb +25 -24
- data/test/tc/path_parts.rb +54 -20
- data/test/tc/paths.rb +3 -2
- data/test/tc/piper.rb +32 -31
- data/test/tc/programs_util.rb +9 -9
- data/test/tc/qae.rb +9 -8
- data/test/tc/qae_riovar.rb +9 -8
- data/test/tc/records.rb +3 -2
- data/test/tc/rename.rb +4 -4
- data/test/tc/riorl.rb +19 -19
- data/test/tc/rlparts.ans.yml +1161 -0
- data/test/tc/splitlines.rb +1 -1
- data/test/tc/splitpath.rb +9 -8
- data/test/tc/strio.rb +73 -0
- data/test/tc/symlink.rb +3 -2
- data/test/tc/symlink0.rb +4 -3
- data/test/tc/symlink1.rb +4 -3
- data/test/tc/temp.rb +40 -26
- data/test/tc/tempdir.rb +12 -12
- data/test/tc/testcase.rb +45 -31
- data/test/tc/tonl.rb +0 -1
- data/test/tc/truncate.rb +111 -13
- data/test/tc/yaml.rb +1 -1
- data/test/test_suite.rb +31 -0
- data/test/tests.rb +35 -0
- data/test/tsuite.rb +19 -0
- data/test/uriref/tc/basic.rb +171 -0
- data/test/uriref/tc/build.rb +30 -0
- data/test/uriref/tc/empty.rb +13 -0
- data/test/uriref/tc/route.rb +72 -0
- data/test/uriref/tests.rb +16 -0
- metadata +356 -424
- data/ChangeLog +0 -3122
- data/VERSION +0 -1
- data/build_doc.rb +0 -94
- data/doc/ANNOUNCE +0 -157
- data/doc/RELEASE_NOTES +0 -308
- data/doc/RIOIS +0 -215
- data/doc/generators/template/html/rio.css +0 -428
- data/doc/generators/template/html/rio.rb +0 -523
- data/doc/generators/template/html/ugly.rb +0 -132
- data/doc/pkg_def.rb +0 -60
- data/doc/rdoc/classes/Kernel.html +0 -133
- data/doc/rdoc/classes/Kernel.src/M000234.html +0 -18
- data/doc/rdoc/classes/RIO.html +0 -625
- data/doc/rdoc/classes/RIO.src/M000001.html +0 -18
- data/doc/rdoc/classes/RIO.src/M000002.html +0 -18
- data/doc/rdoc/classes/RIO.src/M000003.html +0 -18
- data/doc/rdoc/classes/RIO/Doc.html +0 -149
- data/doc/rdoc/classes/RIO/Doc/EXAMPLES.html +0 -432
- data/doc/rdoc/classes/RIO/Doc/HOWTO.html +0 -1084
- data/doc/rdoc/classes/RIO/Doc/INDEX.html +0 -368
- data/doc/rdoc/classes/RIO/Doc/INTRO.html +0 -1529
- data/doc/rdoc/classes/RIO/Doc/OPTIONAL.html +0 -221
- data/doc/rdoc/classes/RIO/Doc/SYNOPSIS.html +0 -336
- data/doc/rdoc/classes/RIO/IF.html +0 -165
- data/doc/rdoc/classes/RIO/IF/CSV.html +0 -203
- data/doc/rdoc/classes/RIO/IF/CSV.src/M000129.html +0 -19
- data/doc/rdoc/classes/RIO/IF/CSV.src/M000130.html +0 -16
- data/doc/rdoc/classes/RIO/IF/CSV.src/M000131.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.html +0 -343
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000045.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000046.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000047.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000048.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000049.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000050.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Dir.src/M000051.html +0 -16
- data/doc/rdoc/classes/RIO/IF/File.html +0 -223
- data/doc/rdoc/classes/RIO/IF/File.src/M000216.html +0 -16
- data/doc/rdoc/classes/RIO/IF/File.src/M000217.html +0 -16
- data/doc/rdoc/classes/RIO/IF/File.src/M000218.html +0 -16
- data/doc/rdoc/classes/RIO/IF/File.src/M000219.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.html +0 -572
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000117.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000118.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000119.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000120.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000121.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000122.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000123.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000124.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000125.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000126.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000127.html +0 -16
- data/doc/rdoc/classes/RIO/IF/FileOrDir.src/M000128.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.html +0 -1376
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000052.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000053.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000054.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000055.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000056.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000057.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000058.html +0 -21
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000059.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000060.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000061.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000062.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000063.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000064.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000065.html +0 -21
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000066.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000067.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000068.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000069.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Grande.src/M000070.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.html +0 -810
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000107.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000108.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000109.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000110.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000111.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000112.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000113.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000114.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000115.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeEntry.src/M000116.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.html +0 -1513
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000071.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000072.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000073.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000074.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000075.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000076.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000077.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000078.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000079.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000080.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000081.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000082.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000083.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000084.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000085.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000086.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000087.html +0 -19
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000088.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000089.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000090.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000091.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000092.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000093.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000094.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000095.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000096.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000097.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000098.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000099.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000100.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000101.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000102.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000103.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000104.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000105.html +0 -16
- data/doc/rdoc/classes/RIO/IF/GrandeStream.src/M000106.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.html +0 -999
- data/doc/rdoc/classes/RIO/IF/Path.src/M000132.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000133.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000134.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000135.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000136.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000137.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000138.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000139.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000140.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000141.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000142.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000143.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000144.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000145.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000146.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000147.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000148.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000149.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000150.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000151.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000152.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000153.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000154.html +0 -18
- data/doc/rdoc/classes/RIO/IF/Path.src/M000155.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000156.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000157.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000158.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000159.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000160.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000161.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000162.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Path.src/M000163.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.html +0 -1416
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000004.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000005.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000006.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000007.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000008.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000009.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000010.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000011.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000012.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000013.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000014.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000015.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000016.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000017.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000018.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000019.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000020.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000021.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000022.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000023.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000024.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000025.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000026.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000027.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000028.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000029.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000030.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000031.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000032.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000033.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000034.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000035.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000036.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000037.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000038.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000039.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000040.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000041.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000042.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000043.html +0 -16
- data/doc/rdoc/classes/RIO/IF/RubyIO.src/M000044.html +0 -16
- data/doc/rdoc/classes/RIO/IF/String.html +0 -203
- data/doc/rdoc/classes/RIO/IF/String.src/M000213.html +0 -16
- data/doc/rdoc/classes/RIO/IF/String.src/M000214.html +0 -16
- data/doc/rdoc/classes/RIO/IF/String.src/M000215.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.html +0 -990
- data/doc/rdoc/classes/RIO/IF/Test.src/M000177.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000178.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000179.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000180.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000181.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000182.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000183.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000184.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000185.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000186.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000187.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000188.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000189.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000190.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000191.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000192.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000193.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000194.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000195.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000196.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000197.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000198.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000199.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000200.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000201.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000202.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000203.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000204.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000205.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000206.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000207.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000208.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000209.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000210.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000211.html +0 -16
- data/doc/rdoc/classes/RIO/IF/Test.src/M000212.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.html +0 -517
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000164.html +0 -19
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000165.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000166.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000167.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000168.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000169.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000170.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000171.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000172.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000173.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000174.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000175.html +0 -16
- data/doc/rdoc/classes/RIO/IF/YAML.src/M000176.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.html +0 -508
- data/doc/rdoc/classes/RIO/Rio.src/M000220.html +0 -18
- data/doc/rdoc/classes/RIO/Rio.src/M000221.html +0 -20
- data/doc/rdoc/classes/RIO/Rio.src/M000222.html +0 -27
- data/doc/rdoc/classes/RIO/Rio.src/M000223.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000225.html +0 -19
- data/doc/rdoc/classes/RIO/Rio.src/M000226.html +0 -20
- data/doc/rdoc/classes/RIO/Rio.src/M000227.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000228.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000229.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000230.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000231.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000232.html +0 -16
- data/doc/rdoc/classes/RIO/Rio.src/M000233.html +0 -16
- data/doc/rdoc/created.rid +0 -1
- data/doc/rdoc/files/README.html +0 -232
- data/doc/rdoc/files/lib/rio/constructor_rb.html +0 -141
- data/doc/rdoc/files/lib/rio/doc/EXAMPLES_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/doc/HOWTO_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/doc/INDEX_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/doc/INTRO_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/doc/OPTIONAL_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/doc/SYNOPSIS_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/basic_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/csv_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/dir_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/file_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/fileordir_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/grande_entry_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/grande_rb.html +0 -141
- data/doc/rdoc/files/lib/rio/if/grande_stream_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/internal_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/path_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/rubyio_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/string_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/temp_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/test_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/if/yaml_rb.html +0 -134
- data/doc/rdoc/files/lib/rio/kernel_rb.html +0 -142
- data/doc/rdoc/files/lib/rio_rb.html +0 -153
- data/doc/rdoc/fr_class_index.html +0 -49
- data/doc/rdoc/fr_file_index.html +0 -51
- data/doc/rdoc/fr_method_index.html +0 -260
- data/doc/rdoc/index.html +0 -30
- data/doc/rdoc/rdoc-style.css +0 -428
- data/doc/rfc1738.txt +0 -1403
- data/doc/rfc959.txt +0 -3933
- data/ex/catcsv.rb +0 -64
- data/ex/colx.rb +0 -8
- data/ex/findinruby +0 -15
- data/ex/findruby +0 -14
- data/ex/passwd_report.rb +0 -8
- data/ex/prompt.rb +0 -25
- data/ex/rgb.txt.gz +0 -0
- data/ex/riocat +0 -42
- data/ex/riogunzip +0 -31
- data/ex/riogzip +0 -24
- data/ex/rioprompt.rb +0 -10
- data/ex/targz2zip +0 -17
- data/ex/tonl +0 -10
- data/setup.rb +0 -1360
- data/test/ftp/all.rb +0 -9
- data/test/ftp/anon_copy_data.rb +0 -36
- data/test/ftp/anon_misc.rb +0 -124
- data/test/ftp/anon_read.rb +0 -105
- data/test/ftp/anon_special.rb +0 -68
- data/test/ftp/anon_write.rb +0 -70
- data/test/ftp/ftp2ftp.rb +0 -51
- data/test/tc/abs.rb +0 -355
data/doc/rfc959.txt
DELETED
|
@@ -1,3933 +0,0 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
Network Working Group J. Postel
|
|
4
|
-
Request for Comments: 959 J. Reynolds
|
|
5
|
-
ISI
|
|
6
|
-
Obsoletes RFC: 765 (IEN 149) October 1985
|
|
7
|
-
|
|
8
|
-
FILE TRANSFER PROTOCOL (FTP)
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
Status of this Memo
|
|
12
|
-
|
|
13
|
-
This memo is the official specification of the File Transfer
|
|
14
|
-
Protocol (FTP). Distribution of this memo is unlimited.
|
|
15
|
-
|
|
16
|
-
The following new optional commands are included in this edition of
|
|
17
|
-
the specification:
|
|
18
|
-
|
|
19
|
-
CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
|
|
20
|
-
(Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
|
|
21
|
-
(Print Directory), and SYST (System).
|
|
22
|
-
|
|
23
|
-
Note that this specification is compatible with the previous edition.
|
|
24
|
-
|
|
25
|
-
1. INTRODUCTION
|
|
26
|
-
|
|
27
|
-
The objectives of FTP are 1) to promote sharing of files (computer
|
|
28
|
-
programs and/or data), 2) to encourage indirect or implicit (via
|
|
29
|
-
programs) use of remote computers, 3) to shield a user from
|
|
30
|
-
variations in file storage systems among hosts, and 4) to transfer
|
|
31
|
-
data reliably and efficiently. FTP, though usable directly by a user
|
|
32
|
-
at a terminal, is designed mainly for use by programs.
|
|
33
|
-
|
|
34
|
-
The attempt in this specification is to satisfy the diverse needs of
|
|
35
|
-
users of maxi-hosts, mini-hosts, personal workstations, and TACs,
|
|
36
|
-
with a simple, and easily implemented protocol design.
|
|
37
|
-
|
|
38
|
-
This paper assumes knowledge of the Transmission Control Protocol
|
|
39
|
-
(TCP) [2] and the Telnet Protocol [3]. These documents are contained
|
|
40
|
-
in the ARPA-Internet protocol handbook [1].
|
|
41
|
-
|
|
42
|
-
2. OVERVIEW
|
|
43
|
-
|
|
44
|
-
In this section, the history, the terminology, and the FTP model are
|
|
45
|
-
discussed. The terms defined in this section are only those that
|
|
46
|
-
have special significance in FTP. Some of the terminology is very
|
|
47
|
-
specific to the FTP model; some readers may wish to turn to the
|
|
48
|
-
section on the FTP model while reviewing the terminology.
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
Postel & Reynolds [Page 1]
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
RFC 959 October 1985
|
|
61
|
-
File Transfer Protocol
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
2.1. HISTORY
|
|
65
|
-
|
|
66
|
-
FTP has had a long evolution over the years. Appendix III is a
|
|
67
|
-
chronological compilation of Request for Comments documents
|
|
68
|
-
relating to FTP. These include the first proposed file transfer
|
|
69
|
-
mechanisms in 1971 that were developed for implementation on hosts
|
|
70
|
-
at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
|
|
71
|
-
|
|
72
|
-
RFC 172 provided a user-level oriented protocol for file transfer
|
|
73
|
-
between host computers (including terminal IMPs). A revision of
|
|
74
|
-
this as RFC 265, restated FTP for additional review, while RFC 281
|
|
75
|
-
suggested further changes. The use of a "Set Data Type"
|
|
76
|
-
transaction was proposed in RFC 294 in January 1982.
|
|
77
|
-
|
|
78
|
-
RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol
|
|
79
|
-
was now defined as a protocol for file transfer between HOSTs on
|
|
80
|
-
the ARPANET, with the primary function of FTP defined as
|
|
81
|
-
transfering files efficiently and reliably among hosts and
|
|
82
|
-
allowing the convenient use of remote file storage capabilities.
|
|
83
|
-
RFC 385 further commented on errors, emphasis points, and
|
|
84
|
-
additions to the protocol, while RFC 414 provided a status report
|
|
85
|
-
on the working server and user FTPs. RFC 430, issued in 1973,
|
|
86
|
-
(among other RFCs too numerous to mention) presented further
|
|
87
|
-
comments on FTP. Finally, an "official" FTP document was
|
|
88
|
-
published as RFC 454.
|
|
89
|
-
|
|
90
|
-
By July 1973, considerable changes from the last versions of FTP
|
|
91
|
-
were made, but the general structure remained the same. RFC 542
|
|
92
|
-
was published as a new "official" specification to reflect these
|
|
93
|
-
changes. However, many implementations based on the older
|
|
94
|
-
specification were not updated.
|
|
95
|
-
|
|
96
|
-
In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624
|
|
97
|
-
proposed further design changes and minor modifications. In 1975,
|
|
98
|
-
RFC 686 entitled, "Leaving Well Enough Alone", discussed the
|
|
99
|
-
differences between all of the early and later versions of FTP.
|
|
100
|
-
RFC 691 presented a minor revision of RFC 686, regarding the
|
|
101
|
-
subject of print files.
|
|
102
|
-
|
|
103
|
-
Motivated by the transition from the NCP to the TCP as the
|
|
104
|
-
underlying protocol, a phoenix was born out of all of the above
|
|
105
|
-
efforts in RFC 765 as the specification of FTP for use on TCP.
|
|
106
|
-
|
|
107
|
-
This current edition of the FTP specification is intended to
|
|
108
|
-
correct some minor documentation errors, to improve the
|
|
109
|
-
explanation of some protocol features, and to add some new
|
|
110
|
-
optional commands.
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
Postel & Reynolds [Page 2]
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
RFC 959 October 1985
|
|
118
|
-
File Transfer Protocol
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
In particular, the following new optional commands are included in
|
|
122
|
-
this edition of the specification:
|
|
123
|
-
|
|
124
|
-
CDUP - Change to Parent Directory
|
|
125
|
-
|
|
126
|
-
SMNT - Structure Mount
|
|
127
|
-
|
|
128
|
-
STOU - Store Unique
|
|
129
|
-
|
|
130
|
-
RMD - Remove Directory
|
|
131
|
-
|
|
132
|
-
MKD - Make Directory
|
|
133
|
-
|
|
134
|
-
PWD - Print Directory
|
|
135
|
-
|
|
136
|
-
SYST - System
|
|
137
|
-
|
|
138
|
-
This specification is compatible with the previous edition. A
|
|
139
|
-
program implemented in conformance to the previous specification
|
|
140
|
-
should automatically be in conformance to this specification.
|
|
141
|
-
|
|
142
|
-
2.2. TERMINOLOGY
|
|
143
|
-
|
|
144
|
-
ASCII
|
|
145
|
-
|
|
146
|
-
The ASCII character set is as defined in the ARPA-Internet
|
|
147
|
-
Protocol Handbook. In FTP, ASCII characters are defined to be
|
|
148
|
-
the lower half of an eight-bit code set (i.e., the most
|
|
149
|
-
significant bit is zero).
|
|
150
|
-
|
|
151
|
-
access controls
|
|
152
|
-
|
|
153
|
-
Access controls define users' access privileges to the use of a
|
|
154
|
-
system, and to the files in that system. Access controls are
|
|
155
|
-
necessary to prevent unauthorized or accidental use of files.
|
|
156
|
-
It is the prerogative of a server-FTP process to invoke access
|
|
157
|
-
controls.
|
|
158
|
-
|
|
159
|
-
byte size
|
|
160
|
-
|
|
161
|
-
There are two byte sizes of interest in FTP: the logical byte
|
|
162
|
-
size of the file, and the transfer byte size used for the
|
|
163
|
-
transmission of the data. The transfer byte size is always 8
|
|
164
|
-
bits. The transfer byte size is not necessarily the byte size
|
|
165
|
-
in which data is to be stored in a system, nor the logical byte
|
|
166
|
-
size for interpretation of the structure of the data.
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
Postel & Reynolds [Page 3]
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
RFC 959 October 1985
|
|
175
|
-
File Transfer Protocol
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
control connection
|
|
179
|
-
|
|
180
|
-
The communication path between the USER-PI and SERVER-PI for
|
|
181
|
-
the exchange of commands and replies. This connection follows
|
|
182
|
-
the Telnet Protocol.
|
|
183
|
-
|
|
184
|
-
data connection
|
|
185
|
-
|
|
186
|
-
A full duplex connection over which data is transferred, in a
|
|
187
|
-
specified mode and type. The data transferred may be a part of
|
|
188
|
-
a file, an entire file or a number of files. The path may be
|
|
189
|
-
between a server-DTP and a user-DTP, or between two
|
|
190
|
-
server-DTPs.
|
|
191
|
-
|
|
192
|
-
data port
|
|
193
|
-
|
|
194
|
-
The passive data transfer process "listens" on the data port
|
|
195
|
-
for a connection from the active transfer process in order to
|
|
196
|
-
open the data connection.
|
|
197
|
-
|
|
198
|
-
DTP
|
|
199
|
-
|
|
200
|
-
The data transfer process establishes and manages the data
|
|
201
|
-
connection. The DTP can be passive or active.
|
|
202
|
-
|
|
203
|
-
End-of-Line
|
|
204
|
-
|
|
205
|
-
The end-of-line sequence defines the separation of printing
|
|
206
|
-
lines. The sequence is Carriage Return, followed by Line Feed.
|
|
207
|
-
|
|
208
|
-
EOF
|
|
209
|
-
|
|
210
|
-
The end-of-file condition that defines the end of a file being
|
|
211
|
-
transferred.
|
|
212
|
-
|
|
213
|
-
EOR
|
|
214
|
-
|
|
215
|
-
The end-of-record condition that defines the end of a record
|
|
216
|
-
being transferred.
|
|
217
|
-
|
|
218
|
-
error recovery
|
|
219
|
-
|
|
220
|
-
A procedure that allows a user to recover from certain errors
|
|
221
|
-
such as failure of either host system or transfer process. In
|
|
222
|
-
FTP, error recovery may involve restarting a file transfer at a
|
|
223
|
-
given checkpoint.
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
Postel & Reynolds [Page 4]
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
RFC 959 October 1985
|
|
232
|
-
File Transfer Protocol
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
FTP commands
|
|
236
|
-
|
|
237
|
-
A set of commands that comprise the control information flowing
|
|
238
|
-
from the user-FTP to the server-FTP process.
|
|
239
|
-
|
|
240
|
-
file
|
|
241
|
-
|
|
242
|
-
An ordered set of computer data (including programs), of
|
|
243
|
-
arbitrary length, uniquely identified by a pathname.
|
|
244
|
-
|
|
245
|
-
mode
|
|
246
|
-
|
|
247
|
-
The mode in which data is to be transferred via the data
|
|
248
|
-
connection. The mode defines the data format during transfer
|
|
249
|
-
including EOR and EOF. The transfer modes defined in FTP are
|
|
250
|
-
described in the Section on Transmission Modes.
|
|
251
|
-
|
|
252
|
-
NVT
|
|
253
|
-
|
|
254
|
-
The Network Virtual Terminal as defined in the Telnet Protocol.
|
|
255
|
-
|
|
256
|
-
NVFS
|
|
257
|
-
|
|
258
|
-
The Network Virtual File System. A concept which defines a
|
|
259
|
-
standard network file system with standard commands and
|
|
260
|
-
pathname conventions.
|
|
261
|
-
|
|
262
|
-
page
|
|
263
|
-
|
|
264
|
-
A file may be structured as a set of independent parts called
|
|
265
|
-
pages. FTP supports the transmission of discontinuous files as
|
|
266
|
-
independent indexed pages.
|
|
267
|
-
|
|
268
|
-
pathname
|
|
269
|
-
|
|
270
|
-
Pathname is defined to be the character string which must be
|
|
271
|
-
input to a file system by a user in order to identify a file.
|
|
272
|
-
Pathname normally contains device and/or directory names, and
|
|
273
|
-
file name specification. FTP does not yet specify a standard
|
|
274
|
-
pathname convention. Each user must follow the file naming
|
|
275
|
-
conventions of the file systems involved in the transfer.
|
|
276
|
-
|
|
277
|
-
PI
|
|
278
|
-
|
|
279
|
-
The protocol interpreter. The user and server sides of the
|
|
280
|
-
protocol have distinct roles implemented in a user-PI and a
|
|
281
|
-
server-PI.
|
|
282
|
-
|
|
283
|
-
|
|
284
|
-
Postel & Reynolds [Page 5]
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
RFC 959 October 1985
|
|
289
|
-
File Transfer Protocol
|
|
290
|
-
|
|
291
|
-
|
|
292
|
-
record
|
|
293
|
-
|
|
294
|
-
A sequential file may be structured as a number of contiguous
|
|
295
|
-
parts called records. Record structures are supported by FTP
|
|
296
|
-
but a file need not have record structure.
|
|
297
|
-
|
|
298
|
-
reply
|
|
299
|
-
|
|
300
|
-
A reply is an acknowledgment (positive or negative) sent from
|
|
301
|
-
server to user via the control connection in response to FTP
|
|
302
|
-
commands. The general form of a reply is a completion code
|
|
303
|
-
(including error codes) followed by a text string. The codes
|
|
304
|
-
are for use by programs and the text is usually intended for
|
|
305
|
-
human users.
|
|
306
|
-
|
|
307
|
-
server-DTP
|
|
308
|
-
|
|
309
|
-
The data transfer process, in its normal "active" state,
|
|
310
|
-
establishes the data connection with the "listening" data port.
|
|
311
|
-
It sets up parameters for transfer and storage, and transfers
|
|
312
|
-
data on command from its PI. The DTP can be placed in a
|
|
313
|
-
"passive" state to listen for, rather than initiate a
|
|
314
|
-
connection on the data port.
|
|
315
|
-
|
|
316
|
-
server-FTP process
|
|
317
|
-
|
|
318
|
-
A process or set of processes which perform the function of
|
|
319
|
-
file transfer in cooperation with a user-FTP process and,
|
|
320
|
-
possibly, another server. The functions consist of a protocol
|
|
321
|
-
interpreter (PI) and a data transfer process (DTP).
|
|
322
|
-
|
|
323
|
-
server-PI
|
|
324
|
-
|
|
325
|
-
The server protocol interpreter "listens" on Port L for a
|
|
326
|
-
connection from a user-PI and establishes a control
|
|
327
|
-
communication connection. It receives standard FTP commands
|
|
328
|
-
from the user-PI, sends replies, and governs the server-DTP.
|
|
329
|
-
|
|
330
|
-
type
|
|
331
|
-
|
|
332
|
-
The data representation type used for data transfer and
|
|
333
|
-
storage. Type implies certain transformations between the time
|
|
334
|
-
of data storage and data transfer. The representation types
|
|
335
|
-
defined in FTP are described in the Section on Establishing
|
|
336
|
-
Data Connections.
|
|
337
|
-
|
|
338
|
-
|
|
339
|
-
|
|
340
|
-
|
|
341
|
-
Postel & Reynolds [Page 6]
|
|
342
|
-
|
|
343
|
-
|
|
344
|
-
|
|
345
|
-
RFC 959 October 1985
|
|
346
|
-
File Transfer Protocol
|
|
347
|
-
|
|
348
|
-
|
|
349
|
-
user
|
|
350
|
-
|
|
351
|
-
A person or a process on behalf of a person wishing to obtain
|
|
352
|
-
file transfer service. The human user may interact directly
|
|
353
|
-
with a server-FTP process, but use of a user-FTP process is
|
|
354
|
-
preferred since the protocol design is weighted towards
|
|
355
|
-
automata.
|
|
356
|
-
|
|
357
|
-
user-DTP
|
|
358
|
-
|
|
359
|
-
The data transfer process "listens" on the data port for a
|
|
360
|
-
connection from a server-FTP process. If two servers are
|
|
361
|
-
transferring data between them, the user-DTP is inactive.
|
|
362
|
-
|
|
363
|
-
user-FTP process
|
|
364
|
-
|
|
365
|
-
A set of functions including a protocol interpreter, a data
|
|
366
|
-
transfer process and a user interface which together perform
|
|
367
|
-
the function of file transfer in cooperation with one or more
|
|
368
|
-
server-FTP processes. The user interface allows a local
|
|
369
|
-
language to be used in the command-reply dialogue with the
|
|
370
|
-
user.
|
|
371
|
-
|
|
372
|
-
user-PI
|
|
373
|
-
|
|
374
|
-
The user protocol interpreter initiates the control connection
|
|
375
|
-
from its port U to the server-FTP process, initiates FTP
|
|
376
|
-
commands, and governs the user-DTP if that process is part of
|
|
377
|
-
the file transfer.
|
|
378
|
-
|
|
379
|
-
|
|
380
|
-
|
|
381
|
-
|
|
382
|
-
|
|
383
|
-
|
|
384
|
-
|
|
385
|
-
|
|
386
|
-
|
|
387
|
-
|
|
388
|
-
|
|
389
|
-
|
|
390
|
-
|
|
391
|
-
|
|
392
|
-
|
|
393
|
-
|
|
394
|
-
|
|
395
|
-
|
|
396
|
-
|
|
397
|
-
|
|
398
|
-
Postel & Reynolds [Page 7]
|
|
399
|
-
|
|
400
|
-
|
|
401
|
-
|
|
402
|
-
RFC 959 October 1985
|
|
403
|
-
File Transfer Protocol
|
|
404
|
-
|
|
405
|
-
|
|
406
|
-
2.3. THE FTP MODEL
|
|
407
|
-
|
|
408
|
-
With the above definitions in mind, the following model (shown in
|
|
409
|
-
Figure 1) may be diagrammed for an FTP service.
|
|
410
|
-
|
|
411
|
-
-------------
|
|
412
|
-
|/---------\|
|
|
413
|
-
|| User || --------
|
|
414
|
-
||Interface|<--->| User |
|
|
415
|
-
|\----^----/| --------
|
|
416
|
-
---------- | | |
|
|
417
|
-
|/------\| FTP Commands |/----V----\|
|
|
418
|
-
||Server|<---------------->| User ||
|
|
419
|
-
|| PI || FTP Replies || PI ||
|
|
420
|
-
|\--^---/| |\----^----/|
|
|
421
|
-
| | | | | |
|
|
422
|
-
-------- |/--V---\| Data |/----V----\| --------
|
|
423
|
-
| File |<--->|Server|<---------------->| User |<--->| File |
|
|
424
|
-
|System| || DTP || Connection || DTP || |System|
|
|
425
|
-
-------- |\------/| |\---------/| --------
|
|
426
|
-
---------- -------------
|
|
427
|
-
|
|
428
|
-
Server-FTP USER-FTP
|
|
429
|
-
|
|
430
|
-
NOTES: 1. The data connection may be used in either direction.
|
|
431
|
-
2. The data connection need not exist all of the time.
|
|
432
|
-
|
|
433
|
-
Figure 1 Model for FTP Use
|
|
434
|
-
|
|
435
|
-
In the model described in Figure 1, the user-protocol interpreter
|
|
436
|
-
initiates the control connection. The control connection follows
|
|
437
|
-
the Telnet protocol. At the initiation of the user, standard FTP
|
|
438
|
-
commands are generated by the user-PI and transmitted to the
|
|
439
|
-
server process via the control connection. (The user may
|
|
440
|
-
establish a direct control connection to the server-FTP, from a
|
|
441
|
-
TAC terminal for example, and generate standard FTP commands
|
|
442
|
-
independently, bypassing the user-FTP process.) Standard replies
|
|
443
|
-
are sent from the server-PI to the user-PI over the control
|
|
444
|
-
connection in response to the commands.
|
|
445
|
-
|
|
446
|
-
The FTP commands specify the parameters for the data connection
|
|
447
|
-
(data port, transfer mode, representation type, and structure) and
|
|
448
|
-
the nature of file system operation (store, retrieve, append,
|
|
449
|
-
delete, etc.). The user-DTP or its designate should "listen" on
|
|
450
|
-
the specified data port, and the server initiate the data
|
|
451
|
-
connection and data transfer in accordance with the specified
|
|
452
|
-
parameters. It should be noted that the data port need not be in
|
|
453
|
-
|
|
454
|
-
|
|
455
|
-
Postel & Reynolds [Page 8]
|
|
456
|
-
|
|
457
|
-
|
|
458
|
-
|
|
459
|
-
RFC 959 October 1985
|
|
460
|
-
File Transfer Protocol
|
|
461
|
-
|
|
462
|
-
|
|
463
|
-
the same host that initiates the FTP commands via the control
|
|
464
|
-
connection, but the user or the user-FTP process must ensure a
|
|
465
|
-
"listen" on the specified data port. It ought to also be noted
|
|
466
|
-
that the data connection may be used for simultaneous sending and
|
|
467
|
-
receiving.
|
|
468
|
-
|
|
469
|
-
In another situation a user might wish to transfer files between
|
|
470
|
-
two hosts, neither of which is a local host. The user sets up
|
|
471
|
-
control connections to the two servers and then arranges for a
|
|
472
|
-
data connection between them. In this manner, control information
|
|
473
|
-
is passed to the user-PI but data is transferred between the
|
|
474
|
-
server data transfer processes. Following is a model of this
|
|
475
|
-
server-server interaction.
|
|
476
|
-
|
|
477
|
-
|
|
478
|
-
Control ------------ Control
|
|
479
|
-
---------->| User-FTP |<-----------
|
|
480
|
-
| | User-PI | |
|
|
481
|
-
| | "C" | |
|
|
482
|
-
V ------------ V
|
|
483
|
-
-------------- --------------
|
|
484
|
-
| Server-FTP | Data Connection | Server-FTP |
|
|
485
|
-
| "A" |<---------------------->| "B" |
|
|
486
|
-
-------------- Port (A) Port (B) --------------
|
|
487
|
-
|
|
488
|
-
|
|
489
|
-
Figure 2
|
|
490
|
-
|
|
491
|
-
The protocol requires that the control connections be open while
|
|
492
|
-
data transfer is in progress. It is the responsibility of the
|
|
493
|
-
user to request the closing of the control connections when
|
|
494
|
-
finished using the FTP service, while it is the server who takes
|
|
495
|
-
the action. The server may abort data transfer if the control
|
|
496
|
-
connections are closed without command.
|
|
497
|
-
|
|
498
|
-
The Relationship between FTP and Telnet:
|
|
499
|
-
|
|
500
|
-
The FTP uses the Telnet protocol on the control connection.
|
|
501
|
-
This can be achieved in two ways: first, the user-PI or the
|
|
502
|
-
server-PI may implement the rules of the Telnet Protocol
|
|
503
|
-
directly in their own procedures; or, second, the user-PI or
|
|
504
|
-
the server-PI may make use of the existing Telnet module in the
|
|
505
|
-
system.
|
|
506
|
-
|
|
507
|
-
Ease of implementaion, sharing code, and modular programming
|
|
508
|
-
argue for the second approach. Efficiency and independence
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
Postel & Reynolds [Page 9]
|
|
513
|
-
|
|
514
|
-
|
|
515
|
-
|
|
516
|
-
RFC 959 October 1985
|
|
517
|
-
File Transfer Protocol
|
|
518
|
-
|
|
519
|
-
|
|
520
|
-
argue for the first approach. In practice, FTP relies on very
|
|
521
|
-
little of the Telnet Protocol, so the first approach does not
|
|
522
|
-
necessarily involve a large amount of code.
|
|
523
|
-
|
|
524
|
-
3. DATA TRANSFER FUNCTIONS
|
|
525
|
-
|
|
526
|
-
Files are transferred only via the data connection. The control
|
|
527
|
-
connection is used for the transfer of commands, which describe the
|
|
528
|
-
functions to be performed, and the replies to these commands (see the
|
|
529
|
-
Section on FTP Replies). Several commands are concerned with the
|
|
530
|
-
transfer of data between hosts. These data transfer commands include
|
|
531
|
-
the MODE command which specify how the bits of the data are to be
|
|
532
|
-
transmitted, and the STRUcture and TYPE commands, which are used to
|
|
533
|
-
define the way in which the data are to be represented. The
|
|
534
|
-
transmission and representation are basically independent but the
|
|
535
|
-
"Stream" transmission mode is dependent on the file structure
|
|
536
|
-
attribute and if "Compressed" transmission mode is used, the nature
|
|
537
|
-
of the filler byte depends on the representation type.
|
|
538
|
-
|
|
539
|
-
3.1. DATA REPRESENTATION AND STORAGE
|
|
540
|
-
|
|
541
|
-
Data is transferred from a storage device in the sending host to a
|
|
542
|
-
storage device in the receiving host. Often it is necessary to
|
|
543
|
-
perform certain transformations on the data because data storage
|
|
544
|
-
representations in the two systems are different. For example,
|
|
545
|
-
NVT-ASCII has different data storage representations in different
|
|
546
|
-
systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
|
|
547
|
-
ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
|
|
548
|
-
store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII
|
|
549
|
-
as four 9-bit characters in a 36-bit word. It is desirable to
|
|
550
|
-
convert characters into the standard NVT-ASCII representation when
|
|
551
|
-
transmitting text between dissimilar systems. The sending and
|
|
552
|
-
receiving sites would have to perform the necessary
|
|
553
|
-
transformations between the standard representation and their
|
|
554
|
-
internal representations.
|
|
555
|
-
|
|
556
|
-
A different problem in representation arises when transmitting
|
|
557
|
-
binary data (not character codes) between host systems with
|
|
558
|
-
different word lengths. It is not always clear how the sender
|
|
559
|
-
should send data, and the receiver store it. For example, when
|
|
560
|
-
transmitting 32-bit bytes from a 32-bit word-length system to a
|
|
561
|
-
36-bit word-length system, it may be desirable (for reasons of
|
|
562
|
-
efficiency and usefulness) to store the 32-bit bytes
|
|
563
|
-
right-justified in a 36-bit word in the latter system. In any
|
|
564
|
-
case, the user should have the option of specifying data
|
|
565
|
-
representation and transformation functions. It should be noted
|
|
566
|
-
|
|
567
|
-
|
|
568
|
-
|
|
569
|
-
Postel & Reynolds [Page 10]
|
|
570
|
-
|
|
571
|
-
|
|
572
|
-
|
|
573
|
-
RFC 959 October 1985
|
|
574
|
-
File Transfer Protocol
|
|
575
|
-
|
|
576
|
-
|
|
577
|
-
that FTP provides for very limited data type representations.
|
|
578
|
-
Transformations desired beyond this limited capability should be
|
|
579
|
-
performed by the user directly.
|
|
580
|
-
|
|
581
|
-
3.1.1. DATA TYPES
|
|
582
|
-
|
|
583
|
-
Data representations are handled in FTP by a user specifying a
|
|
584
|
-
representation type. This type may implicitly (as in ASCII or
|
|
585
|
-
EBCDIC) or explicitly (as in Local byte) define a byte size for
|
|
586
|
-
interpretation which is referred to as the "logical byte size."
|
|
587
|
-
Note that this has nothing to do with the byte size used for
|
|
588
|
-
transmission over the data connection, called the "transfer
|
|
589
|
-
byte size", and the two should not be confused. For example,
|
|
590
|
-
NVT-ASCII has a logical byte size of 8 bits. If the type is
|
|
591
|
-
Local byte, then the TYPE command has an obligatory second
|
|
592
|
-
parameter specifying the logical byte size. The transfer byte
|
|
593
|
-
size is always 8 bits.
|
|
594
|
-
|
|
595
|
-
3.1.1.1. ASCII TYPE
|
|
596
|
-
|
|
597
|
-
This is the default type and must be accepted by all FTP
|
|
598
|
-
implementations. It is intended primarily for the transfer
|
|
599
|
-
of text files, except when both hosts would find the EBCDIC
|
|
600
|
-
type more convenient.
|
|
601
|
-
|
|
602
|
-
The sender converts the data from an internal character
|
|
603
|
-
representation to the standard 8-bit NVT-ASCII
|
|
604
|
-
representation (see the Telnet specification). The receiver
|
|
605
|
-
will convert the data from the standard form to his own
|
|
606
|
-
internal form.
|
|
607
|
-
|
|
608
|
-
In accordance with the NVT standard, the <CRLF> sequence
|
|
609
|
-
should be used where necessary to denote the end of a line
|
|
610
|
-
of text. (See the discussion of file structure at the end
|
|
611
|
-
of the Section on Data Representation and Storage.)
|
|
612
|
-
|
|
613
|
-
Using the standard NVT-ASCII representation means that data
|
|
614
|
-
must be interpreted as 8-bit bytes.
|
|
615
|
-
|
|
616
|
-
The Format parameter for ASCII and EBCDIC types is discussed
|
|
617
|
-
below.
|
|
618
|
-
|
|
619
|
-
|
|
620
|
-
|
|
621
|
-
|
|
622
|
-
|
|
623
|
-
|
|
624
|
-
|
|
625
|
-
|
|
626
|
-
Postel & Reynolds [Page 11]
|
|
627
|
-
|
|
628
|
-
|
|
629
|
-
|
|
630
|
-
RFC 959 October 1985
|
|
631
|
-
File Transfer Protocol
|
|
632
|
-
|
|
633
|
-
|
|
634
|
-
3.1.1.2. EBCDIC TYPE
|
|
635
|
-
|
|
636
|
-
This type is intended for efficient transfer between hosts
|
|
637
|
-
which use EBCDIC for their internal character
|
|
638
|
-
representation.
|
|
639
|
-
|
|
640
|
-
For transmission, the data are represented as 8-bit EBCDIC
|
|
641
|
-
characters. The character code is the only difference
|
|
642
|
-
between the functional specifications of EBCDIC and ASCII
|
|
643
|
-
types.
|
|
644
|
-
|
|
645
|
-
End-of-line (as opposed to end-of-record--see the discussion
|
|
646
|
-
of structure) will probably be rarely used with EBCDIC type
|
|
647
|
-
for purposes of denoting structure, but where it is
|
|
648
|
-
necessary the <NL> character should be used.
|
|
649
|
-
|
|
650
|
-
3.1.1.3. IMAGE TYPE
|
|
651
|
-
|
|
652
|
-
The data are sent as contiguous bits which, for transfer,
|
|
653
|
-
are packed into the 8-bit transfer bytes. The receiving
|
|
654
|
-
site must store the data as contiguous bits. The structure
|
|
655
|
-
of the storage system might necessitate the padding of the
|
|
656
|
-
file (or of each record, for a record-structured file) to
|
|
657
|
-
some convenient boundary (byte, word or block). This
|
|
658
|
-
padding, which must be all zeros, may occur only at the end
|
|
659
|
-
of the file (or at the end of each record) and there must be
|
|
660
|
-
a way of identifying the padding bits so that they may be
|
|
661
|
-
stripped off if the file is retrieved. The padding
|
|
662
|
-
transformation should be well publicized to enable a user to
|
|
663
|
-
process a file at the storage site.
|
|
664
|
-
|
|
665
|
-
Image type is intended for the efficient storage and
|
|
666
|
-
retrieval of files and for the transfer of binary data. It
|
|
667
|
-
is recommended that this type be accepted by all FTP
|
|
668
|
-
implementations.
|
|
669
|
-
|
|
670
|
-
3.1.1.4. LOCAL TYPE
|
|
671
|
-
|
|
672
|
-
The data is transferred in logical bytes of the size
|
|
673
|
-
specified by the obligatory second parameter, Byte size.
|
|
674
|
-
The value of Byte size must be a decimal integer; there is
|
|
675
|
-
no default value. The logical byte size is not necessarily
|
|
676
|
-
the same as the transfer byte size. If there is a
|
|
677
|
-
difference in byte sizes, then the logical bytes should be
|
|
678
|
-
packed contiguously, disregarding transfer byte boundaries
|
|
679
|
-
and with any necessary padding at the end.
|
|
680
|
-
|
|
681
|
-
|
|
682
|
-
|
|
683
|
-
Postel & Reynolds [Page 12]
|
|
684
|
-
|
|
685
|
-
|
|
686
|
-
|
|
687
|
-
RFC 959 October 1985
|
|
688
|
-
File Transfer Protocol
|
|
689
|
-
|
|
690
|
-
|
|
691
|
-
When the data reaches the receiving host, it will be
|
|
692
|
-
transformed in a manner dependent on the logical byte size
|
|
693
|
-
and the particular host. This transformation must be
|
|
694
|
-
invertible (i.e., an identical file can be retrieved if the
|
|
695
|
-
same parameters are used) and should be well publicized by
|
|
696
|
-
the FTP implementors.
|
|
697
|
-
|
|
698
|
-
For example, a user sending 36-bit floating-point numbers to
|
|
699
|
-
a host with a 32-bit word could send that data as Local byte
|
|
700
|
-
with a logical byte size of 36. The receiving host would
|
|
701
|
-
then be expected to store the logical bytes so that they
|
|
702
|
-
could be easily manipulated; in this example putting the
|
|
703
|
-
36-bit logical bytes into 64-bit double words should
|
|
704
|
-
suffice.
|
|
705
|
-
|
|
706
|
-
In another example, a pair of hosts with a 36-bit word size
|
|
707
|
-
may send data to one another in words by using TYPE L 36.
|
|
708
|
-
The data would be sent in the 8-bit transmission bytes
|
|
709
|
-
packed so that 9 transmission bytes carried two host words.
|
|
710
|
-
|
|
711
|
-
3.1.1.5. FORMAT CONTROL
|
|
712
|
-
|
|
713
|
-
The types ASCII and EBCDIC also take a second (optional)
|
|
714
|
-
parameter; this is to indicate what kind of vertical format
|
|
715
|
-
control, if any, is associated with a file. The following
|
|
716
|
-
data representation types are defined in FTP:
|
|
717
|
-
|
|
718
|
-
A character file may be transferred to a host for one of
|
|
719
|
-
three purposes: for printing, for storage and later
|
|
720
|
-
retrieval, or for processing. If a file is sent for
|
|
721
|
-
printing, the receiving host must know how the vertical
|
|
722
|
-
format control is represented. In the second case, it must
|
|
723
|
-
be possible to store a file at a host and then retrieve it
|
|
724
|
-
later in exactly the same form. Finally, it should be
|
|
725
|
-
possible to move a file from one host to another and process
|
|
726
|
-
the file at the second host without undue trouble. A single
|
|
727
|
-
ASCII or EBCDIC format does not satisfy all these
|
|
728
|
-
conditions. Therefore, these types have a second parameter
|
|
729
|
-
specifying one of the following three formats:
|
|
730
|
-
|
|
731
|
-
3.1.1.5.1. NON PRINT
|
|
732
|
-
|
|
733
|
-
This is the default format to be used if the second
|
|
734
|
-
(format) parameter is omitted. Non-print format must be
|
|
735
|
-
accepted by all FTP implementations.
|
|
736
|
-
|
|
737
|
-
|
|
738
|
-
|
|
739
|
-
|
|
740
|
-
Postel & Reynolds [Page 13]
|
|
741
|
-
|
|
742
|
-
|
|
743
|
-
|
|
744
|
-
RFC 959 October 1985
|
|
745
|
-
File Transfer Protocol
|
|
746
|
-
|
|
747
|
-
|
|
748
|
-
The file need contain no vertical format information. If
|
|
749
|
-
it is passed to a printer process, this process may
|
|
750
|
-
assume standard values for spacing and margins.
|
|
751
|
-
|
|
752
|
-
Normally, this format will be used with files destined
|
|
753
|
-
for processing or just storage.
|
|
754
|
-
|
|
755
|
-
3.1.1.5.2. TELNET FORMAT CONTROLS
|
|
756
|
-
|
|
757
|
-
The file contains ASCII/EBCDIC vertical format controls
|
|
758
|
-
(i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
|
|
759
|
-
process will interpret appropriately. <CRLF>, in exactly
|
|
760
|
-
this sequence, also denotes end-of-line.
|
|
761
|
-
|
|
762
|
-
3.1.1.5.2. CARRIAGE CONTROL (ASA)
|
|
763
|
-
|
|
764
|
-
The file contains ASA (FORTRAN) vertical format control
|
|
765
|
-
characters. (See RFC 740 Appendix C; and Communications
|
|
766
|
-
of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a
|
|
767
|
-
line or a record formatted according to the ASA Standard,
|
|
768
|
-
the first character is not to be printed. Instead, it
|
|
769
|
-
should be used to determine the vertical movement of the
|
|
770
|
-
paper which should take place before the rest of the
|
|
771
|
-
record is printed.
|
|
772
|
-
|
|
773
|
-
The ASA Standard specifies the following control
|
|
774
|
-
characters:
|
|
775
|
-
|
|
776
|
-
Character Vertical Spacing
|
|
777
|
-
|
|
778
|
-
blank Move paper up one line
|
|
779
|
-
0 Move paper up two lines
|
|
780
|
-
1 Move paper to top of next page
|
|
781
|
-
+ No movement, i.e., overprint
|
|
782
|
-
|
|
783
|
-
Clearly there must be some way for a printer process to
|
|
784
|
-
distinguish the end of the structural entity. If a file
|
|
785
|
-
has record structure (see below) this is no problem;
|
|
786
|
-
records will be explicitly marked during transfer and
|
|
787
|
-
storage. If the file has no record structure, the <CRLF>
|
|
788
|
-
end-of-line sequence is used to separate printing lines,
|
|
789
|
-
but these format effectors are overridden by the ASA
|
|
790
|
-
controls.
|
|
791
|
-
|
|
792
|
-
|
|
793
|
-
|
|
794
|
-
|
|
795
|
-
|
|
796
|
-
|
|
797
|
-
Postel & Reynolds [Page 14]
|
|
798
|
-
|
|
799
|
-
|
|
800
|
-
|
|
801
|
-
RFC 959 October 1985
|
|
802
|
-
File Transfer Protocol
|
|
803
|
-
|
|
804
|
-
|
|
805
|
-
3.1.2. DATA STRUCTURES
|
|
806
|
-
|
|
807
|
-
In addition to different representation types, FTP allows the
|
|
808
|
-
structure of a file to be specified. Three file structures are
|
|
809
|
-
defined in FTP:
|
|
810
|
-
|
|
811
|
-
file-structure, where there is no internal structure and
|
|
812
|
-
the file is considered to be a
|
|
813
|
-
continuous sequence of data bytes,
|
|
814
|
-
|
|
815
|
-
record-structure, where the file is made up of sequential
|
|
816
|
-
records,
|
|
817
|
-
|
|
818
|
-
and page-structure, where the file is made up of independent
|
|
819
|
-
indexed pages.
|
|
820
|
-
|
|
821
|
-
File-structure is the default to be assumed if the STRUcture
|
|
822
|
-
command has not been used but both file and record structures
|
|
823
|
-
must be accepted for "text" files (i.e., files with TYPE ASCII
|
|
824
|
-
or EBCDIC) by all FTP implementations. The structure of a file
|
|
825
|
-
will affect both the transfer mode of a file (see the Section
|
|
826
|
-
on Transmission Modes) and the interpretation and storage of
|
|
827
|
-
the file.
|
|
828
|
-
|
|
829
|
-
The "natural" structure of a file will depend on which host
|
|
830
|
-
stores the file. A source-code file will usually be stored on
|
|
831
|
-
an IBM Mainframe in fixed length records but on a DEC TOPS-20
|
|
832
|
-
as a stream of characters partitioned into lines, for example
|
|
833
|
-
by <CRLF>. If the transfer of files between such disparate
|
|
834
|
-
sites is to be useful, there must be some way for one site to
|
|
835
|
-
recognize the other's assumptions about the file.
|
|
836
|
-
|
|
837
|
-
With some sites being naturally file-oriented and others
|
|
838
|
-
naturally record-oriented there may be problems if a file with
|
|
839
|
-
one structure is sent to a host oriented to the other. If a
|
|
840
|
-
text file is sent with record-structure to a host which is file
|
|
841
|
-
oriented, then that host should apply an internal
|
|
842
|
-
transformation to the file based on the record structure.
|
|
843
|
-
Obviously, this transformation should be useful, but it must
|
|
844
|
-
also be invertible so that an identical file may be retrieved
|
|
845
|
-
using record structure.
|
|
846
|
-
|
|
847
|
-
In the case of a file being sent with file-structure to a
|
|
848
|
-
record-oriented host, there exists the question of what
|
|
849
|
-
criteria the host should use to divide the file into records
|
|
850
|
-
which can be processed locally. If this division is necessary,
|
|
851
|
-
the FTP implementation should use the end-of-line sequence,
|
|
852
|
-
|
|
853
|
-
|
|
854
|
-
Postel & Reynolds [Page 15]
|
|
855
|
-
|
|
856
|
-
|
|
857
|
-
|
|
858
|
-
RFC 959 October 1985
|
|
859
|
-
File Transfer Protocol
|
|
860
|
-
|
|
861
|
-
|
|
862
|
-
<CRLF> for ASCII, or <NL> for EBCDIC text files, as the
|
|
863
|
-
delimiter. If an FTP implementation adopts this technique, it
|
|
864
|
-
must be prepared to reverse the transformation if the file is
|
|
865
|
-
retrieved with file-structure.
|
|
866
|
-
|
|
867
|
-
3.1.2.1. FILE STRUCTURE
|
|
868
|
-
|
|
869
|
-
File structure is the default to be assumed if the STRUcture
|
|
870
|
-
command has not been used.
|
|
871
|
-
|
|
872
|
-
In file-structure there is no internal structure and the
|
|
873
|
-
file is considered to be a continuous sequence of data
|
|
874
|
-
bytes.
|
|
875
|
-
|
|
876
|
-
3.1.2.2. RECORD STRUCTURE
|
|
877
|
-
|
|
878
|
-
Record structures must be accepted for "text" files (i.e.,
|
|
879
|
-
files with TYPE ASCII or EBCDIC) by all FTP implementations.
|
|
880
|
-
|
|
881
|
-
In record-structure the file is made up of sequential
|
|
882
|
-
records.
|
|
883
|
-
|
|
884
|
-
3.1.2.3. PAGE STRUCTURE
|
|
885
|
-
|
|
886
|
-
To transmit files that are discontinuous, FTP defines a page
|
|
887
|
-
structure. Files of this type are sometimes known as
|
|
888
|
-
"random access files" or even as "holey files". In these
|
|
889
|
-
files there is sometimes other information associated with
|
|
890
|
-
the file as a whole (e.g., a file descriptor), or with a
|
|
891
|
-
section of the file (e.g., page access controls), or both.
|
|
892
|
-
In FTP, the sections of the file are called pages.
|
|
893
|
-
|
|
894
|
-
To provide for various page sizes and associated
|
|
895
|
-
information, each page is sent with a page header. The page
|
|
896
|
-
header has the following defined fields:
|
|
897
|
-
|
|
898
|
-
Header Length
|
|
899
|
-
|
|
900
|
-
The number of logical bytes in the page header
|
|
901
|
-
including this byte. The minimum header length is 4.
|
|
902
|
-
|
|
903
|
-
Page Index
|
|
904
|
-
|
|
905
|
-
The logical page number of this section of the file.
|
|
906
|
-
This is not the transmission sequence number of this
|
|
907
|
-
page, but the index used to identify this page of the
|
|
908
|
-
file.
|
|
909
|
-
|
|
910
|
-
|
|
911
|
-
Postel & Reynolds [Page 16]
|
|
912
|
-
|
|
913
|
-
|
|
914
|
-
|
|
915
|
-
RFC 959 October 1985
|
|
916
|
-
File Transfer Protocol
|
|
917
|
-
|
|
918
|
-
|
|
919
|
-
Data Length
|
|
920
|
-
|
|
921
|
-
The number of logical bytes in the page data. The
|
|
922
|
-
minimum data length is 0.
|
|
923
|
-
|
|
924
|
-
Page Type
|
|
925
|
-
|
|
926
|
-
The type of page this is. The following page types
|
|
927
|
-
are defined:
|
|
928
|
-
|
|
929
|
-
0 = Last Page
|
|
930
|
-
|
|
931
|
-
This is used to indicate the end of a paged
|
|
932
|
-
structured transmission. The header length must
|
|
933
|
-
be 4, and the data length must be 0.
|
|
934
|
-
|
|
935
|
-
1 = Simple Page
|
|
936
|
-
|
|
937
|
-
This is the normal type for simple paged files
|
|
938
|
-
with no page level associated control
|
|
939
|
-
information. The header length must be 4.
|
|
940
|
-
|
|
941
|
-
2 = Descriptor Page
|
|
942
|
-
|
|
943
|
-
This type is used to transmit the descriptive
|
|
944
|
-
information for the file as a whole.
|
|
945
|
-
|
|
946
|
-
3 = Access Controlled Page
|
|
947
|
-
|
|
948
|
-
This type includes an additional header field
|
|
949
|
-
for paged files with page level access control
|
|
950
|
-
information. The header length must be 5.
|
|
951
|
-
|
|
952
|
-
Optional Fields
|
|
953
|
-
|
|
954
|
-
Further header fields may be used to supply per page
|
|
955
|
-
control information, for example, per page access
|
|
956
|
-
control.
|
|
957
|
-
|
|
958
|
-
All fields are one logical byte in length. The logical byte
|
|
959
|
-
size is specified by the TYPE command. See Appendix I for
|
|
960
|
-
further details and a specific case at the page structure.
|
|
961
|
-
|
|
962
|
-
A note of caution about parameters: a file must be stored and
|
|
963
|
-
retrieved with the same parameters if the retrieved version is to
|
|
964
|
-
|
|
965
|
-
|
|
966
|
-
|
|
967
|
-
|
|
968
|
-
Postel & Reynolds [Page 17]
|
|
969
|
-
|
|
970
|
-
|
|
971
|
-
|
|
972
|
-
RFC 959 October 1985
|
|
973
|
-
File Transfer Protocol
|
|
974
|
-
|
|
975
|
-
|
|
976
|
-
be identical to the version originally transmitted. Conversely,
|
|
977
|
-
FTP implementations must return a file identical to the original
|
|
978
|
-
if the parameters used to store and retrieve a file are the same.
|
|
979
|
-
|
|
980
|
-
3.2. ESTABLISHING DATA CONNECTIONS
|
|
981
|
-
|
|
982
|
-
The mechanics of transferring data consists of setting up the data
|
|
983
|
-
connection to the appropriate ports and choosing the parameters
|
|
984
|
-
for transfer. Both the user and the server-DTPs have a default
|
|
985
|
-
data port. The user-process default data port is the same as the
|
|
986
|
-
control connection port (i.e., U). The server-process default
|
|
987
|
-
data port is the port adjacent to the control connection port
|
|
988
|
-
(i.e., L-1).
|
|
989
|
-
|
|
990
|
-
The transfer byte size is 8-bit bytes. This byte size is relevant
|
|
991
|
-
only for the actual transfer of the data; it has no bearing on
|
|
992
|
-
representation of the data within a host's file system.
|
|
993
|
-
|
|
994
|
-
The passive data transfer process (this may be a user-DTP or a
|
|
995
|
-
second server-DTP) shall "listen" on the data port prior to
|
|
996
|
-
sending a transfer request command. The FTP request command
|
|
997
|
-
determines the direction of the data transfer. The server, upon
|
|
998
|
-
receiving the transfer request, will initiate the data connection
|
|
999
|
-
to the port. When the connection is established, the data
|
|
1000
|
-
transfer begins between DTP's, and the server-PI sends a
|
|
1001
|
-
confirming reply to the user-PI.
|
|
1002
|
-
|
|
1003
|
-
Every FTP implementation must support the use of the default data
|
|
1004
|
-
ports, and only the USER-PI can initiate a change to non-default
|
|
1005
|
-
ports.
|
|
1006
|
-
|
|
1007
|
-
It is possible for the user to specify an alternate data port by
|
|
1008
|
-
use of the PORT command. The user may want a file dumped on a TAC
|
|
1009
|
-
line printer or retrieved from a third party host. In the latter
|
|
1010
|
-
case, the user-PI sets up control connections with both
|
|
1011
|
-
server-PI's. One server is then told (by an FTP command) to
|
|
1012
|
-
"listen" for a connection which the other will initiate. The
|
|
1013
|
-
user-PI sends one server-PI a PORT command indicating the data
|
|
1014
|
-
port of the other. Finally, both are sent the appropriate
|
|
1015
|
-
transfer commands. The exact sequence of commands and replies
|
|
1016
|
-
sent between the user-controller and the servers is defined in the
|
|
1017
|
-
Section on FTP Replies.
|
|
1018
|
-
|
|
1019
|
-
In general, it is the server's responsibility to maintain the data
|
|
1020
|
-
connection--to initiate it and to close it. The exception to this
|
|
1021
|
-
|
|
1022
|
-
|
|
1023
|
-
|
|
1024
|
-
|
|
1025
|
-
Postel & Reynolds [Page 18]
|
|
1026
|
-
|
|
1027
|
-
|
|
1028
|
-
|
|
1029
|
-
RFC 959 October 1985
|
|
1030
|
-
File Transfer Protocol
|
|
1031
|
-
|
|
1032
|
-
|
|
1033
|
-
is when the user-DTP is sending the data in a transfer mode that
|
|
1034
|
-
requires the connection to be closed to indicate EOF. The server
|
|
1035
|
-
MUST close the data connection under the following conditions:
|
|
1036
|
-
|
|
1037
|
-
1. The server has completed sending data in a transfer mode
|
|
1038
|
-
that requires a close to indicate EOF.
|
|
1039
|
-
|
|
1040
|
-
2. The server receives an ABORT command from the user.
|
|
1041
|
-
|
|
1042
|
-
3. The port specification is changed by a command from the
|
|
1043
|
-
user.
|
|
1044
|
-
|
|
1045
|
-
4. The control connection is closed legally or otherwise.
|
|
1046
|
-
|
|
1047
|
-
5. An irrecoverable error condition occurs.
|
|
1048
|
-
|
|
1049
|
-
Otherwise the close is a server option, the exercise of which the
|
|
1050
|
-
server must indicate to the user-process by either a 250 or 226
|
|
1051
|
-
reply only.
|
|
1052
|
-
|
|
1053
|
-
3.3. DATA CONNECTION MANAGEMENT
|
|
1054
|
-
|
|
1055
|
-
Default Data Connection Ports: All FTP implementations must
|
|
1056
|
-
support use of the default data connection ports, and only the
|
|
1057
|
-
User-PI may initiate the use of non-default ports.
|
|
1058
|
-
|
|
1059
|
-
Negotiating Non-Default Data Ports: The User-PI may specify a
|
|
1060
|
-
non-default user side data port with the PORT command. The
|
|
1061
|
-
User-PI may request the server side to identify a non-default
|
|
1062
|
-
server side data port with the PASV command. Since a connection
|
|
1063
|
-
is defined by the pair of addresses, either of these actions is
|
|
1064
|
-
enough to get a different data connection, still it is permitted
|
|
1065
|
-
to do both commands to use new ports on both ends of the data
|
|
1066
|
-
connection.
|
|
1067
|
-
|
|
1068
|
-
Reuse of the Data Connection: When using the stream mode of data
|
|
1069
|
-
transfer the end of the file must be indicated by closing the
|
|
1070
|
-
connection. This causes a problem if multiple files are to be
|
|
1071
|
-
transfered in the session, due to need for TCP to hold the
|
|
1072
|
-
connection record for a time out period to guarantee the reliable
|
|
1073
|
-
communication. Thus the connection can not be reopened at once.
|
|
1074
|
-
|
|
1075
|
-
There are two solutions to this problem. The first is to
|
|
1076
|
-
negotiate a non-default port. The second is to use another
|
|
1077
|
-
transfer mode.
|
|
1078
|
-
|
|
1079
|
-
A comment on transfer modes. The stream transfer mode is
|
|
1080
|
-
|
|
1081
|
-
|
|
1082
|
-
Postel & Reynolds [Page 19]
|
|
1083
|
-
|
|
1084
|
-
|
|
1085
|
-
|
|
1086
|
-
RFC 959 October 1985
|
|
1087
|
-
File Transfer Protocol
|
|
1088
|
-
|
|
1089
|
-
|
|
1090
|
-
inherently unreliable, since one can not determine if the
|
|
1091
|
-
connection closed prematurely or not. The other transfer modes
|
|
1092
|
-
(Block, Compressed) do not close the connection to indicate the
|
|
1093
|
-
end of file. They have enough FTP encoding that the data
|
|
1094
|
-
connection can be parsed to determine the end of the file.
|
|
1095
|
-
Thus using these modes one can leave the data connection open
|
|
1096
|
-
for multiple file transfers.
|
|
1097
|
-
|
|
1098
|
-
3.4. TRANSMISSION MODES
|
|
1099
|
-
|
|
1100
|
-
The next consideration in transferring data is choosing the
|
|
1101
|
-
appropriate transmission mode. There are three modes: one which
|
|
1102
|
-
formats the data and allows for restart procedures; one which also
|
|
1103
|
-
compresses the data for efficient transfer; and one which passes
|
|
1104
|
-
the data with little or no processing. In this last case the mode
|
|
1105
|
-
interacts with the structure attribute to determine the type of
|
|
1106
|
-
processing. In the compressed mode, the representation type
|
|
1107
|
-
determines the filler byte.
|
|
1108
|
-
|
|
1109
|
-
All data transfers must be completed with an end-of-file (EOF)
|
|
1110
|
-
which may be explicitly stated or implied by the closing of the
|
|
1111
|
-
data connection. For files with record structure, all the
|
|
1112
|
-
end-of-record markers (EOR) are explicit, including the final one.
|
|
1113
|
-
For files transmitted in page structure a "last-page" page type is
|
|
1114
|
-
used.
|
|
1115
|
-
|
|
1116
|
-
NOTE: In the rest of this section, byte means "transfer byte"
|
|
1117
|
-
except where explicitly stated otherwise.
|
|
1118
|
-
|
|
1119
|
-
For the purpose of standardized transfer, the sending host will
|
|
1120
|
-
translate its internal end of line or end of record denotation
|
|
1121
|
-
into the representation prescribed by the transfer mode and file
|
|
1122
|
-
structure, and the receiving host will perform the inverse
|
|
1123
|
-
translation to its internal denotation. An IBM Mainframe record
|
|
1124
|
-
count field may not be recognized at another host, so the
|
|
1125
|
-
end-of-record information may be transferred as a two byte control
|
|
1126
|
-
code in Stream mode or as a flagged bit in a Block or Compressed
|
|
1127
|
-
mode descriptor. End-of-line in an ASCII or EBCDIC file with no
|
|
1128
|
-
record structure should be indicated by <CRLF> or <NL>,
|
|
1129
|
-
respectively. Since these transformations imply extra work for
|
|
1130
|
-
some systems, identical systems transferring non-record structured
|
|
1131
|
-
text files might wish to use a binary representation and stream
|
|
1132
|
-
mode for the transfer.
|
|
1133
|
-
|
|
1134
|
-
|
|
1135
|
-
|
|
1136
|
-
|
|
1137
|
-
|
|
1138
|
-
|
|
1139
|
-
Postel & Reynolds [Page 20]
|
|
1140
|
-
|
|
1141
|
-
|
|
1142
|
-
|
|
1143
|
-
RFC 959 October 1985
|
|
1144
|
-
File Transfer Protocol
|
|
1145
|
-
|
|
1146
|
-
|
|
1147
|
-
The following transmission modes are defined in FTP:
|
|
1148
|
-
|
|
1149
|
-
3.4.1. STREAM MODE
|
|
1150
|
-
|
|
1151
|
-
The data is transmitted as a stream of bytes. There is no
|
|
1152
|
-
restriction on the representation type used; record structures
|
|
1153
|
-
are allowed.
|
|
1154
|
-
|
|
1155
|
-
In a record structured file EOR and EOF will each be indicated
|
|
1156
|
-
by a two-byte control code. The first byte of the control code
|
|
1157
|
-
will be all ones, the escape character. The second byte will
|
|
1158
|
-
have the low order bit on and zeros elsewhere for EOR and the
|
|
1159
|
-
second low order bit on for EOF; that is, the byte will have
|
|
1160
|
-
value 1 for EOR and value 2 for EOF. EOR and EOF may be
|
|
1161
|
-
indicated together on the last byte transmitted by turning both
|
|
1162
|
-
low order bits on (i.e., the value 3). If a byte of all ones
|
|
1163
|
-
was intended to be sent as data, it should be repeated in the
|
|
1164
|
-
second byte of the control code.
|
|
1165
|
-
|
|
1166
|
-
If the structure is a file structure, the EOF is indicated by
|
|
1167
|
-
the sending host closing the data connection and all bytes are
|
|
1168
|
-
data bytes.
|
|
1169
|
-
|
|
1170
|
-
3.4.2. BLOCK MODE
|
|
1171
|
-
|
|
1172
|
-
The file is transmitted as a series of data blocks preceded by
|
|
1173
|
-
one or more header bytes. The header bytes contain a count
|
|
1174
|
-
field, and descriptor code. The count field indicates the
|
|
1175
|
-
total length of the data block in bytes, thus marking the
|
|
1176
|
-
beginning of the next data block (there are no filler bits).
|
|
1177
|
-
The descriptor code defines: last block in the file (EOF) last
|
|
1178
|
-
block in the record (EOR), restart marker (see the Section on
|
|
1179
|
-
Error Recovery and Restart) or suspect data (i.e., the data
|
|
1180
|
-
being transferred is suspected of errors and is not reliable).
|
|
1181
|
-
This last code is NOT intended for error control within FTP.
|
|
1182
|
-
It is motivated by the desire of sites exchanging certain types
|
|
1183
|
-
of data (e.g., seismic or weather data) to send and receive all
|
|
1184
|
-
the data despite local errors (such as "magnetic tape read
|
|
1185
|
-
errors"), but to indicate in the transmission that certain
|
|
1186
|
-
portions are suspect). Record structures are allowed in this
|
|
1187
|
-
mode, and any representation type may be used.
|
|
1188
|
-
|
|
1189
|
-
The header consists of the three bytes. Of the 24 bits of
|
|
1190
|
-
header information, the 16 low order bits shall represent byte
|
|
1191
|
-
count, and the 8 high order bits shall represent descriptor
|
|
1192
|
-
codes as shown below.
|
|
1193
|
-
|
|
1194
|
-
|
|
1195
|
-
|
|
1196
|
-
Postel & Reynolds [Page 21]
|
|
1197
|
-
|
|
1198
|
-
|
|
1199
|
-
|
|
1200
|
-
RFC 959 October 1985
|
|
1201
|
-
File Transfer Protocol
|
|
1202
|
-
|
|
1203
|
-
|
|
1204
|
-
Block Header
|
|
1205
|
-
|
|
1206
|
-
+----------------+----------------+----------------+
|
|
1207
|
-
| Descriptor | Byte Count |
|
|
1208
|
-
| 8 bits | 16 bits |
|
|
1209
|
-
+----------------+----------------+----------------+
|
|
1210
|
-
|
|
1211
|
-
|
|
1212
|
-
The descriptor codes are indicated by bit flags in the
|
|
1213
|
-
descriptor byte. Four codes have been assigned, where each
|
|
1214
|
-
code number is the decimal value of the corresponding bit in
|
|
1215
|
-
the byte.
|
|
1216
|
-
|
|
1217
|
-
Code Meaning
|
|
1218
|
-
|
|
1219
|
-
128 End of data block is EOR
|
|
1220
|
-
64 End of data block is EOF
|
|
1221
|
-
32 Suspected errors in data block
|
|
1222
|
-
16 Data block is a restart marker
|
|
1223
|
-
|
|
1224
|
-
With this encoding, more than one descriptor coded condition
|
|
1225
|
-
may exist for a particular block. As many bits as necessary
|
|
1226
|
-
may be flagged.
|
|
1227
|
-
|
|
1228
|
-
The restart marker is embedded in the data stream as an
|
|
1229
|
-
integral number of 8-bit bytes representing printable
|
|
1230
|
-
characters in the language being used over the control
|
|
1231
|
-
connection (e.g., default--NVT-ASCII). <SP> (Space, in the
|
|
1232
|
-
appropriate language) must not be used WITHIN a restart marker.
|
|
1233
|
-
|
|
1234
|
-
For example, to transmit a six-character marker, the following
|
|
1235
|
-
would be sent:
|
|
1236
|
-
|
|
1237
|
-
+--------+--------+--------+
|
|
1238
|
-
|Descrptr| Byte count |
|
|
1239
|
-
|code= 16| = 6 |
|
|
1240
|
-
+--------+--------+--------+
|
|
1241
|
-
|
|
1242
|
-
+--------+--------+--------+
|
|
1243
|
-
| Marker | Marker | Marker |
|
|
1244
|
-
| 8 bits | 8 bits | 8 bits |
|
|
1245
|
-
+--------+--------+--------+
|
|
1246
|
-
|
|
1247
|
-
+--------+--------+--------+
|
|
1248
|
-
| Marker | Marker | Marker |
|
|
1249
|
-
| 8 bits | 8 bits | 8 bits |
|
|
1250
|
-
+--------+--------+--------+
|
|
1251
|
-
|
|
1252
|
-
|
|
1253
|
-
Postel & Reynolds [Page 22]
|
|
1254
|
-
|
|
1255
|
-
|
|
1256
|
-
|
|
1257
|
-
RFC 959 October 1985
|
|
1258
|
-
File Transfer Protocol
|
|
1259
|
-
|
|
1260
|
-
|
|
1261
|
-
3.4.3. COMPRESSED MODE
|
|
1262
|
-
|
|
1263
|
-
There are three kinds of information to be sent: regular data,
|
|
1264
|
-
sent in a byte string; compressed data, consisting of
|
|
1265
|
-
replications or filler; and control information, sent in a
|
|
1266
|
-
two-byte escape sequence. If n>0 bytes (up to 127) of regular
|
|
1267
|
-
data are sent, these n bytes are preceded by a byte with the
|
|
1268
|
-
left-most bit set to 0 and the right-most 7 bits containing the
|
|
1269
|
-
number n.
|
|
1270
|
-
|
|
1271
|
-
Byte string:
|
|
1272
|
-
|
|
1273
|
-
1 7 8 8
|
|
1274
|
-
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
|
1275
|
-
|0| n | | d(1) | ... | d(n) |
|
|
1276
|
-
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
|
1277
|
-
^ ^
|
|
1278
|
-
|---n bytes---|
|
|
1279
|
-
of data
|
|
1280
|
-
|
|
1281
|
-
String of n data bytes d(1),..., d(n)
|
|
1282
|
-
Count n must be positive.
|
|
1283
|
-
|
|
1284
|
-
To compress a string of n replications of the data byte d, the
|
|
1285
|
-
following 2 bytes are sent:
|
|
1286
|
-
|
|
1287
|
-
Replicated Byte:
|
|
1288
|
-
|
|
1289
|
-
2 6 8
|
|
1290
|
-
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
|
1291
|
-
|1 0| n | | d |
|
|
1292
|
-
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|
|
1293
|
-
|
|
1294
|
-
A string of n filler bytes can be compressed into a single
|
|
1295
|
-
byte, where the filler byte varies with the representation
|
|
1296
|
-
type. If the type is ASCII or EBCDIC the filler byte is <SP>
|
|
1297
|
-
(Space, ASCII code 32, EBCDIC code 64). If the type is Image
|
|
1298
|
-
or Local byte the filler is a zero byte.
|
|
1299
|
-
|
|
1300
|
-
Filler String:
|
|
1301
|
-
|
|
1302
|
-
2 6
|
|
1303
|
-
+-+-+-+-+-+-+-+-+
|
|
1304
|
-
|1 1| n |
|
|
1305
|
-
+-+-+-+-+-+-+-+-+
|
|
1306
|
-
|
|
1307
|
-
The escape sequence is a double byte, the first of which is the
|
|
1308
|
-
|
|
1309
|
-
|
|
1310
|
-
Postel & Reynolds [Page 23]
|
|
1311
|
-
|
|
1312
|
-
|
|
1313
|
-
|
|
1314
|
-
RFC 959 October 1985
|
|
1315
|
-
File Transfer Protocol
|
|
1316
|
-
|
|
1317
|
-
|
|
1318
|
-
escape byte (all zeros) and the second of which contains
|
|
1319
|
-
descriptor codes as defined in Block mode. The descriptor
|
|
1320
|
-
codes have the same meaning as in Block mode and apply to the
|
|
1321
|
-
succeeding string of bytes.
|
|
1322
|
-
|
|
1323
|
-
Compressed mode is useful for obtaining increased bandwidth on
|
|
1324
|
-
very large network transmissions at a little extra CPU cost.
|
|
1325
|
-
It can be most effectively used to reduce the size of printer
|
|
1326
|
-
files such as those generated by RJE hosts.
|
|
1327
|
-
|
|
1328
|
-
3.5. ERROR RECOVERY AND RESTART
|
|
1329
|
-
|
|
1330
|
-
There is no provision for detecting bits lost or scrambled in data
|
|
1331
|
-
transfer; this level of error control is handled by the TCP.
|
|
1332
|
-
However, a restart procedure is provided to protect users from
|
|
1333
|
-
gross system failures (including failures of a host, an
|
|
1334
|
-
FTP-process, or the underlying network).
|
|
1335
|
-
|
|
1336
|
-
The restart procedure is defined only for the block and compressed
|
|
1337
|
-
modes of data transfer. It requires the sender of data to insert
|
|
1338
|
-
a special marker code in the data stream with some marker
|
|
1339
|
-
information. The marker information has meaning only to the
|
|
1340
|
-
sender, but must consist of printable characters in the default or
|
|
1341
|
-
negotiated language of the control connection (ASCII or EBCDIC).
|
|
1342
|
-
The marker could represent a bit-count, a record-count, or any
|
|
1343
|
-
other information by which a system may identify a data
|
|
1344
|
-
checkpoint. The receiver of data, if it implements the restart
|
|
1345
|
-
procedure, would then mark the corresponding position of this
|
|
1346
|
-
marker in the receiving system, and return this information to the
|
|
1347
|
-
user.
|
|
1348
|
-
|
|
1349
|
-
In the event of a system failure, the user can restart the data
|
|
1350
|
-
transfer by identifying the marker point with the FTP restart
|
|
1351
|
-
procedure. The following example illustrates the use of the
|
|
1352
|
-
restart procedure.
|
|
1353
|
-
|
|
1354
|
-
The sender of the data inserts an appropriate marker block in the
|
|
1355
|
-
data stream at a convenient point. The receiving host marks the
|
|
1356
|
-
corresponding data point in its file system and conveys the last
|
|
1357
|
-
known sender and receiver marker information to the user, either
|
|
1358
|
-
directly or over the control connection in a 110 reply (depending
|
|
1359
|
-
on who is the sender). In the event of a system failure, the user
|
|
1360
|
-
or controller process restarts the server at the last server
|
|
1361
|
-
marker by sending a restart command with server's marker code as
|
|
1362
|
-
its argument. The restart command is transmitted over the control
|
|
1363
|
-
|
|
1364
|
-
|
|
1365
|
-
|
|
1366
|
-
|
|
1367
|
-
Postel & Reynolds [Page 24]
|
|
1368
|
-
|
|
1369
|
-
|
|
1370
|
-
|
|
1371
|
-
RFC 959 October 1985
|
|
1372
|
-
File Transfer Protocol
|
|
1373
|
-
|
|
1374
|
-
|
|
1375
|
-
connection and is immediately followed by the command (such as
|
|
1376
|
-
RETR, STOR or LIST) which was being executed when the system
|
|
1377
|
-
failure occurred.
|
|
1378
|
-
|
|
1379
|
-
4. FILE TRANSFER FUNCTIONS
|
|
1380
|
-
|
|
1381
|
-
The communication channel from the user-PI to the server-PI is
|
|
1382
|
-
established as a TCP connection from the user to the standard server
|
|
1383
|
-
port. The user protocol interpreter is responsible for sending FTP
|
|
1384
|
-
commands and interpreting the replies received; the server-PI
|
|
1385
|
-
interprets commands, sends replies and directs its DTP to set up the
|
|
1386
|
-
data connection and transfer the data. If the second party to the
|
|
1387
|
-
data transfer (the passive transfer process) is the user-DTP, then it
|
|
1388
|
-
is governed through the internal protocol of the user-FTP host; if it
|
|
1389
|
-
is a second server-DTP, then it is governed by its PI on command from
|
|
1390
|
-
the user-PI. The FTP replies are discussed in the next section. In
|
|
1391
|
-
the description of a few of the commands in this section, it is
|
|
1392
|
-
helpful to be explicit about the possible replies.
|
|
1393
|
-
|
|
1394
|
-
4.1. FTP COMMANDS
|
|
1395
|
-
|
|
1396
|
-
4.1.1. ACCESS CONTROL COMMANDS
|
|
1397
|
-
|
|
1398
|
-
The following commands specify access control identifiers
|
|
1399
|
-
(command codes are shown in parentheses).
|
|
1400
|
-
|
|
1401
|
-
USER NAME (USER)
|
|
1402
|
-
|
|
1403
|
-
The argument field is a Telnet string identifying the user.
|
|
1404
|
-
The user identification is that which is required by the
|
|
1405
|
-
server for access to its file system. This command will
|
|
1406
|
-
normally be the first command transmitted by the user after
|
|
1407
|
-
the control connections are made (some servers may require
|
|
1408
|
-
this). Additional identification information in the form of
|
|
1409
|
-
a password and/or an account command may also be required by
|
|
1410
|
-
some servers. Servers may allow a new USER command to be
|
|
1411
|
-
entered at any point in order to change the access control
|
|
1412
|
-
and/or accounting information. This has the effect of
|
|
1413
|
-
flushing any user, password, and account information already
|
|
1414
|
-
supplied and beginning the login sequence again. All
|
|
1415
|
-
transfer parameters are unchanged and any file transfer in
|
|
1416
|
-
progress is completed under the old access control
|
|
1417
|
-
parameters.
|
|
1418
|
-
|
|
1419
|
-
|
|
1420
|
-
|
|
1421
|
-
|
|
1422
|
-
|
|
1423
|
-
|
|
1424
|
-
Postel & Reynolds [Page 25]
|
|
1425
|
-
|
|
1426
|
-
|
|
1427
|
-
|
|
1428
|
-
RFC 959 October 1985
|
|
1429
|
-
File Transfer Protocol
|
|
1430
|
-
|
|
1431
|
-
|
|
1432
|
-
PASSWORD (PASS)
|
|
1433
|
-
|
|
1434
|
-
The argument field is a Telnet string specifying the user's
|
|
1435
|
-
password. This command must be immediately preceded by the
|
|
1436
|
-
user name command, and, for some sites, completes the user's
|
|
1437
|
-
identification for access control. Since password
|
|
1438
|
-
information is quite sensitive, it is desirable in general
|
|
1439
|
-
to "mask" it or suppress typeout. It appears that the
|
|
1440
|
-
server has no foolproof way to achieve this. It is
|
|
1441
|
-
therefore the responsibility of the user-FTP process to hide
|
|
1442
|
-
the sensitive password information.
|
|
1443
|
-
|
|
1444
|
-
ACCOUNT (ACCT)
|
|
1445
|
-
|
|
1446
|
-
The argument field is a Telnet string identifying the user's
|
|
1447
|
-
account. The command is not necessarily related to the USER
|
|
1448
|
-
command, as some sites may require an account for login and
|
|
1449
|
-
others only for specific access, such as storing files. In
|
|
1450
|
-
the latter case the command may arrive at any time.
|
|
1451
|
-
|
|
1452
|
-
There are reply codes to differentiate these cases for the
|
|
1453
|
-
automation: when account information is required for login,
|
|
1454
|
-
the response to a successful PASSword command is reply code
|
|
1455
|
-
332. On the other hand, if account information is NOT
|
|
1456
|
-
required for login, the reply to a successful PASSword
|
|
1457
|
-
command is 230; and if the account information is needed for
|
|
1458
|
-
a command issued later in the dialogue, the server should
|
|
1459
|
-
return a 332 or 532 reply depending on whether it stores
|
|
1460
|
-
(pending receipt of the ACCounT command) or discards the
|
|
1461
|
-
command, respectively.
|
|
1462
|
-
|
|
1463
|
-
CHANGE WORKING DIRECTORY (CWD)
|
|
1464
|
-
|
|
1465
|
-
This command allows the user to work with a different
|
|
1466
|
-
directory or dataset for file storage or retrieval without
|
|
1467
|
-
altering his login or accounting information. Transfer
|
|
1468
|
-
parameters are similarly unchanged. The argument is a
|
|
1469
|
-
pathname specifying a directory or other system dependent
|
|
1470
|
-
file group designator.
|
|
1471
|
-
|
|
1472
|
-
CHANGE TO PARENT DIRECTORY (CDUP)
|
|
1473
|
-
|
|
1474
|
-
This command is a special case of CWD, and is included to
|
|
1475
|
-
simplify the implementation of programs for transferring
|
|
1476
|
-
directory trees between operating systems having different
|
|
1477
|
-
|
|
1478
|
-
|
|
1479
|
-
|
|
1480
|
-
|
|
1481
|
-
Postel & Reynolds [Page 26]
|
|
1482
|
-
|
|
1483
|
-
|
|
1484
|
-
|
|
1485
|
-
RFC 959 October 1985
|
|
1486
|
-
File Transfer Protocol
|
|
1487
|
-
|
|
1488
|
-
|
|
1489
|
-
syntaxes for naming the parent directory. The reply codes
|
|
1490
|
-
shall be identical to the reply codes of CWD. See
|
|
1491
|
-
Appendix II for further details.
|
|
1492
|
-
|
|
1493
|
-
STRUCTURE MOUNT (SMNT)
|
|
1494
|
-
|
|
1495
|
-
This command allows the user to mount a different file
|
|
1496
|
-
system data structure without altering his login or
|
|
1497
|
-
accounting information. Transfer parameters are similarly
|
|
1498
|
-
unchanged. The argument is a pathname specifying a
|
|
1499
|
-
directory or other system dependent file group designator.
|
|
1500
|
-
|
|
1501
|
-
REINITIALIZE (REIN)
|
|
1502
|
-
|
|
1503
|
-
This command terminates a USER, flushing all I/O and account
|
|
1504
|
-
information, except to allow any transfer in progress to be
|
|
1505
|
-
completed. All parameters are reset to the default settings
|
|
1506
|
-
and the control connection is left open. This is identical
|
|
1507
|
-
to the state in which a user finds himself immediately after
|
|
1508
|
-
the control connection is opened. A USER command may be
|
|
1509
|
-
expected to follow.
|
|
1510
|
-
|
|
1511
|
-
LOGOUT (QUIT)
|
|
1512
|
-
|
|
1513
|
-
This command terminates a USER and if file transfer is not
|
|
1514
|
-
in progress, the server closes the control connection. If
|
|
1515
|
-
file transfer is in progress, the connection will remain
|
|
1516
|
-
open for result response and the server will then close it.
|
|
1517
|
-
If the user-process is transferring files for several USERs
|
|
1518
|
-
but does not wish to close and then reopen connections for
|
|
1519
|
-
each, then the REIN command should be used instead of QUIT.
|
|
1520
|
-
|
|
1521
|
-
An unexpected close on the control connection will cause the
|
|
1522
|
-
server to take the effective action of an abort (ABOR) and a
|
|
1523
|
-
logout (QUIT).
|
|
1524
|
-
|
|
1525
|
-
4.1.2. TRANSFER PARAMETER COMMANDS
|
|
1526
|
-
|
|
1527
|
-
All data transfer parameters have default values, and the
|
|
1528
|
-
commands specifying data transfer parameters are required only
|
|
1529
|
-
if the default parameter values are to be changed. The default
|
|
1530
|
-
value is the last specified value, or if no value has been
|
|
1531
|
-
specified, the standard default value is as stated here. This
|
|
1532
|
-
implies that the server must "remember" the applicable default
|
|
1533
|
-
values. The commands may be in any order except that they must
|
|
1534
|
-
precede the FTP service request. The following commands
|
|
1535
|
-
specify data transfer parameters:
|
|
1536
|
-
|
|
1537
|
-
|
|
1538
|
-
Postel & Reynolds [Page 27]
|
|
1539
|
-
|
|
1540
|
-
|
|
1541
|
-
|
|
1542
|
-
RFC 959 October 1985
|
|
1543
|
-
File Transfer Protocol
|
|
1544
|
-
|
|
1545
|
-
|
|
1546
|
-
DATA PORT (PORT)
|
|
1547
|
-
|
|
1548
|
-
The argument is a HOST-PORT specification for the data port
|
|
1549
|
-
to be used in data connection. There are defaults for both
|
|
1550
|
-
the user and server data ports, and under normal
|
|
1551
|
-
circumstances this command and its reply are not needed. If
|
|
1552
|
-
this command is used, the argument is the concatenation of a
|
|
1553
|
-
32-bit internet host address and a 16-bit TCP port address.
|
|
1554
|
-
This address information is broken into 8-bit fields and the
|
|
1555
|
-
value of each field is transmitted as a decimal number (in
|
|
1556
|
-
character string representation). The fields are separated
|
|
1557
|
-
by commas. A port command would be:
|
|
1558
|
-
|
|
1559
|
-
PORT h1,h2,h3,h4,p1,p2
|
|
1560
|
-
|
|
1561
|
-
where h1 is the high order 8 bits of the internet host
|
|
1562
|
-
address.
|
|
1563
|
-
|
|
1564
|
-
PASSIVE (PASV)
|
|
1565
|
-
|
|
1566
|
-
This command requests the server-DTP to "listen" on a data
|
|
1567
|
-
port (which is not its default data port) and to wait for a
|
|
1568
|
-
connection rather than initiate one upon receipt of a
|
|
1569
|
-
transfer command. The response to this command includes the
|
|
1570
|
-
host and port address this server is listening on.
|
|
1571
|
-
|
|
1572
|
-
REPRESENTATION TYPE (TYPE)
|
|
1573
|
-
|
|
1574
|
-
The argument specifies the representation type as described
|
|
1575
|
-
in the Section on Data Representation and Storage. Several
|
|
1576
|
-
types take a second parameter. The first parameter is
|
|
1577
|
-
denoted by a single Telnet character, as is the second
|
|
1578
|
-
Format parameter for ASCII and EBCDIC; the second parameter
|
|
1579
|
-
for local byte is a decimal integer to indicate Bytesize.
|
|
1580
|
-
The parameters are separated by a <SP> (Space, ASCII code
|
|
1581
|
-
32).
|
|
1582
|
-
|
|
1583
|
-
The following codes are assigned for type:
|
|
1584
|
-
|
|
1585
|
-
\ /
|
|
1586
|
-
A - ASCII | | N - Non-print
|
|
1587
|
-
|-><-| T - Telnet format effectors
|
|
1588
|
-
E - EBCDIC| | C - Carriage Control (ASA)
|
|
1589
|
-
/ \
|
|
1590
|
-
I - Image
|
|
1591
|
-
|
|
1592
|
-
L <byte size> - Local byte Byte size
|
|
1593
|
-
|
|
1594
|
-
|
|
1595
|
-
Postel & Reynolds [Page 28]
|
|
1596
|
-
|
|
1597
|
-
|
|
1598
|
-
|
|
1599
|
-
RFC 959 October 1985
|
|
1600
|
-
File Transfer Protocol
|
|
1601
|
-
|
|
1602
|
-
|
|
1603
|
-
The default representation type is ASCII Non-print. If the
|
|
1604
|
-
Format parameter is changed, and later just the first
|
|
1605
|
-
argument is changed, Format then returns to the Non-print
|
|
1606
|
-
default.
|
|
1607
|
-
|
|
1608
|
-
FILE STRUCTURE (STRU)
|
|
1609
|
-
|
|
1610
|
-
The argument is a single Telnet character code specifying
|
|
1611
|
-
file structure described in the Section on Data
|
|
1612
|
-
Representation and Storage.
|
|
1613
|
-
|
|
1614
|
-
The following codes are assigned for structure:
|
|
1615
|
-
|
|
1616
|
-
F - File (no record structure)
|
|
1617
|
-
R - Record structure
|
|
1618
|
-
P - Page structure
|
|
1619
|
-
|
|
1620
|
-
The default structure is File.
|
|
1621
|
-
|
|
1622
|
-
TRANSFER MODE (MODE)
|
|
1623
|
-
|
|
1624
|
-
The argument is a single Telnet character code specifying
|
|
1625
|
-
the data transfer modes described in the Section on
|
|
1626
|
-
Transmission Modes.
|
|
1627
|
-
|
|
1628
|
-
The following codes are assigned for transfer modes:
|
|
1629
|
-
|
|
1630
|
-
S - Stream
|
|
1631
|
-
B - Block
|
|
1632
|
-
C - Compressed
|
|
1633
|
-
|
|
1634
|
-
The default transfer mode is Stream.
|
|
1635
|
-
|
|
1636
|
-
4.1.3. FTP SERVICE COMMANDS
|
|
1637
|
-
|
|
1638
|
-
The FTP service commands define the file transfer or the file
|
|
1639
|
-
system function requested by the user. The argument of an FTP
|
|
1640
|
-
service command will normally be a pathname. The syntax of
|
|
1641
|
-
pathnames must conform to server site conventions (with
|
|
1642
|
-
standard defaults applicable), and the language conventions of
|
|
1643
|
-
the control connection. The suggested default handling is to
|
|
1644
|
-
use the last specified device, directory or file name, or the
|
|
1645
|
-
standard default defined for local users. The commands may be
|
|
1646
|
-
in any order except that a "rename from" command must be
|
|
1647
|
-
followed by a "rename to" command and the restart command must
|
|
1648
|
-
be followed by the interrupted service command (e.g., STOR or
|
|
1649
|
-
RETR). The data, when transferred in response to FTP service
|
|
1650
|
-
|
|
1651
|
-
|
|
1652
|
-
Postel & Reynolds [Page 29]
|
|
1653
|
-
|
|
1654
|
-
|
|
1655
|
-
|
|
1656
|
-
RFC 959 October 1985
|
|
1657
|
-
File Transfer Protocol
|
|
1658
|
-
|
|
1659
|
-
|
|
1660
|
-
commands, shall always be sent over the data connection, except
|
|
1661
|
-
for certain informative replies. The following commands
|
|
1662
|
-
specify FTP service requests:
|
|
1663
|
-
|
|
1664
|
-
RETRIEVE (RETR)
|
|
1665
|
-
|
|
1666
|
-
This command causes the server-DTP to transfer a copy of the
|
|
1667
|
-
file, specified in the pathname, to the server- or user-DTP
|
|
1668
|
-
at the other end of the data connection. The status and
|
|
1669
|
-
contents of the file at the server site shall be unaffected.
|
|
1670
|
-
|
|
1671
|
-
STORE (STOR)
|
|
1672
|
-
|
|
1673
|
-
This command causes the server-DTP to accept the data
|
|
1674
|
-
transferred via the data connection and to store the data as
|
|
1675
|
-
a file at the server site. If the file specified in the
|
|
1676
|
-
pathname exists at the server site, then its contents shall
|
|
1677
|
-
be replaced by the data being transferred. A new file is
|
|
1678
|
-
created at the server site if the file specified in the
|
|
1679
|
-
pathname does not already exist.
|
|
1680
|
-
|
|
1681
|
-
STORE UNIQUE (STOU)
|
|
1682
|
-
|
|
1683
|
-
This command behaves like STOR except that the resultant
|
|
1684
|
-
file is to be created in the current directory under a name
|
|
1685
|
-
unique to that directory. The 250 Transfer Started response
|
|
1686
|
-
must include the name generated.
|
|
1687
|
-
|
|
1688
|
-
APPEND (with create) (APPE)
|
|
1689
|
-
|
|
1690
|
-
This command causes the server-DTP to accept the data
|
|
1691
|
-
transferred via the data connection and to store the data in
|
|
1692
|
-
a file at the server site. If the file specified in the
|
|
1693
|
-
pathname exists at the server site, then the data shall be
|
|
1694
|
-
appended to that file; otherwise the file specified in the
|
|
1695
|
-
pathname shall be created at the server site.
|
|
1696
|
-
|
|
1697
|
-
ALLOCATE (ALLO)
|
|
1698
|
-
|
|
1699
|
-
This command may be required by some servers to reserve
|
|
1700
|
-
sufficient storage to accommodate the new file to be
|
|
1701
|
-
transferred. The argument shall be a decimal integer
|
|
1702
|
-
representing the number of bytes (using the logical byte
|
|
1703
|
-
size) of storage to be reserved for the file. For files
|
|
1704
|
-
sent with record or page structure a maximum record or page
|
|
1705
|
-
size (in logical bytes) might also be necessary; this is
|
|
1706
|
-
indicated by a decimal integer in a second argument field of
|
|
1707
|
-
|
|
1708
|
-
|
|
1709
|
-
Postel & Reynolds [Page 30]
|
|
1710
|
-
|
|
1711
|
-
|
|
1712
|
-
|
|
1713
|
-
RFC 959 October 1985
|
|
1714
|
-
File Transfer Protocol
|
|
1715
|
-
|
|
1716
|
-
|
|
1717
|
-
the command. This second argument is optional, but when
|
|
1718
|
-
present should be separated from the first by the three
|
|
1719
|
-
Telnet characters <SP> R <SP>. This command shall be
|
|
1720
|
-
followed by a STORe or APPEnd command. The ALLO command
|
|
1721
|
-
should be treated as a NOOP (no operation) by those servers
|
|
1722
|
-
which do not require that the maximum size of the file be
|
|
1723
|
-
declared beforehand, and those servers interested in only
|
|
1724
|
-
the maximum record or page size should accept a dummy value
|
|
1725
|
-
in the first argument and ignore it.
|
|
1726
|
-
|
|
1727
|
-
RESTART (REST)
|
|
1728
|
-
|
|
1729
|
-
The argument field represents the server marker at which
|
|
1730
|
-
file transfer is to be restarted. This command does not
|
|
1731
|
-
cause file transfer but skips over the file to the specified
|
|
1732
|
-
data checkpoint. This command shall be immediately followed
|
|
1733
|
-
by the appropriate FTP service command which shall cause
|
|
1734
|
-
file transfer to resume.
|
|
1735
|
-
|
|
1736
|
-
RENAME FROM (RNFR)
|
|
1737
|
-
|
|
1738
|
-
This command specifies the old pathname of the file which is
|
|
1739
|
-
to be renamed. This command must be immediately followed by
|
|
1740
|
-
a "rename to" command specifying the new file pathname.
|
|
1741
|
-
|
|
1742
|
-
RENAME TO (RNTO)
|
|
1743
|
-
|
|
1744
|
-
This command specifies the new pathname of the file
|
|
1745
|
-
specified in the immediately preceding "rename from"
|
|
1746
|
-
command. Together the two commands cause a file to be
|
|
1747
|
-
renamed.
|
|
1748
|
-
|
|
1749
|
-
ABORT (ABOR)
|
|
1750
|
-
|
|
1751
|
-
This command tells the server to abort the previous FTP
|
|
1752
|
-
service command and any associated transfer of data. The
|
|
1753
|
-
abort command may require "special action", as discussed in
|
|
1754
|
-
the Section on FTP Commands, to force recognition by the
|
|
1755
|
-
server. No action is to be taken if the previous command
|
|
1756
|
-
has been completed (including data transfer). The control
|
|
1757
|
-
connection is not to be closed by the server, but the data
|
|
1758
|
-
connection must be closed.
|
|
1759
|
-
|
|
1760
|
-
There are two cases for the server upon receipt of this
|
|
1761
|
-
command: (1) the FTP service command was already completed,
|
|
1762
|
-
or (2) the FTP service command is still in progress.
|
|
1763
|
-
|
|
1764
|
-
|
|
1765
|
-
|
|
1766
|
-
Postel & Reynolds [Page 31]
|
|
1767
|
-
|
|
1768
|
-
|
|
1769
|
-
|
|
1770
|
-
RFC 959 October 1985
|
|
1771
|
-
File Transfer Protocol
|
|
1772
|
-
|
|
1773
|
-
|
|
1774
|
-
In the first case, the server closes the data connection
|
|
1775
|
-
(if it is open) and responds with a 226 reply, indicating
|
|
1776
|
-
that the abort command was successfully processed.
|
|
1777
|
-
|
|
1778
|
-
In the second case, the server aborts the FTP service in
|
|
1779
|
-
progress and closes the data connection, returning a 426
|
|
1780
|
-
reply to indicate that the service request terminated
|
|
1781
|
-
abnormally. The server then sends a 226 reply,
|
|
1782
|
-
indicating that the abort command was successfully
|
|
1783
|
-
processed.
|
|
1784
|
-
|
|
1785
|
-
DELETE (DELE)
|
|
1786
|
-
|
|
1787
|
-
This command causes the file specified in the pathname to be
|
|
1788
|
-
deleted at the server site. If an extra level of protection
|
|
1789
|
-
is desired (such as the query, "Do you really wish to
|
|
1790
|
-
delete?"), it should be provided by the user-FTP process.
|
|
1791
|
-
|
|
1792
|
-
REMOVE DIRECTORY (RMD)
|
|
1793
|
-
|
|
1794
|
-
This command causes the directory specified in the pathname
|
|
1795
|
-
to be removed as a directory (if the pathname is absolute)
|
|
1796
|
-
or as a subdirectory of the current working directory (if
|
|
1797
|
-
the pathname is relative). See Appendix II.
|
|
1798
|
-
|
|
1799
|
-
MAKE DIRECTORY (MKD)
|
|
1800
|
-
|
|
1801
|
-
This command causes the directory specified in the pathname
|
|
1802
|
-
to be created as a directory (if the pathname is absolute)
|
|
1803
|
-
or as a subdirectory of the current working directory (if
|
|
1804
|
-
the pathname is relative). See Appendix II.
|
|
1805
|
-
|
|
1806
|
-
PRINT WORKING DIRECTORY (PWD)
|
|
1807
|
-
|
|
1808
|
-
This command causes the name of the current working
|
|
1809
|
-
directory to be returned in the reply. See Appendix II.
|
|
1810
|
-
|
|
1811
|
-
LIST (LIST)
|
|
1812
|
-
|
|
1813
|
-
This command causes a list to be sent from the server to the
|
|
1814
|
-
passive DTP. If the pathname specifies a directory or other
|
|
1815
|
-
group of files, the server should transfer a list of files
|
|
1816
|
-
in the specified directory. If the pathname specifies a
|
|
1817
|
-
file then the server should send current information on the
|
|
1818
|
-
file. A null argument implies the user's current working or
|
|
1819
|
-
default directory. The data transfer is over the data
|
|
1820
|
-
connection in type ASCII or type EBCDIC. (The user must
|
|
1821
|
-
|
|
1822
|
-
|
|
1823
|
-
Postel & Reynolds [Page 32]
|
|
1824
|
-
|
|
1825
|
-
|
|
1826
|
-
|
|
1827
|
-
RFC 959 October 1985
|
|
1828
|
-
File Transfer Protocol
|
|
1829
|
-
|
|
1830
|
-
|
|
1831
|
-
ensure that the TYPE is appropriately ASCII or EBCDIC).
|
|
1832
|
-
Since the information on a file may vary widely from system
|
|
1833
|
-
to system, this information may be hard to use automatically
|
|
1834
|
-
in a program, but may be quite useful to a human user.
|
|
1835
|
-
|
|
1836
|
-
NAME LIST (NLST)
|
|
1837
|
-
|
|
1838
|
-
This command causes a directory listing to be sent from
|
|
1839
|
-
server to user site. The pathname should specify a
|
|
1840
|
-
directory or other system-specific file group descriptor; a
|
|
1841
|
-
null argument implies the current directory. The server
|
|
1842
|
-
will return a stream of names of files and no other
|
|
1843
|
-
information. The data will be transferred in ASCII or
|
|
1844
|
-
EBCDIC type over the data connection as valid pathname
|
|
1845
|
-
strings separated by <CRLF> or <NL>. (Again the user must
|
|
1846
|
-
ensure that the TYPE is correct.) This command is intended
|
|
1847
|
-
to return information that can be used by a program to
|
|
1848
|
-
further process the files automatically. For example, in
|
|
1849
|
-
the implementation of a "multiple get" function.
|
|
1850
|
-
|
|
1851
|
-
SITE PARAMETERS (SITE)
|
|
1852
|
-
|
|
1853
|
-
This command is used by the server to provide services
|
|
1854
|
-
specific to his system that are essential to file transfer
|
|
1855
|
-
but not sufficiently universal to be included as commands in
|
|
1856
|
-
the protocol. The nature of these services and the
|
|
1857
|
-
specification of their syntax can be stated in a reply to
|
|
1858
|
-
the HELP SITE command.
|
|
1859
|
-
|
|
1860
|
-
SYSTEM (SYST)
|
|
1861
|
-
|
|
1862
|
-
This command is used to find out the type of operating
|
|
1863
|
-
system at the server. The reply shall have as its first
|
|
1864
|
-
word one of the system names listed in the current version
|
|
1865
|
-
of the Assigned Numbers document [4].
|
|
1866
|
-
|
|
1867
|
-
STATUS (STAT)
|
|
1868
|
-
|
|
1869
|
-
This command shall cause a status response to be sent over
|
|
1870
|
-
the control connection in the form of a reply. The command
|
|
1871
|
-
may be sent during a file transfer (along with the Telnet IP
|
|
1872
|
-
and Synch signals--see the Section on FTP Commands) in which
|
|
1873
|
-
case the server will respond with the status of the
|
|
1874
|
-
operation in progress, or it may be sent between file
|
|
1875
|
-
transfers. In the latter case, the command may have an
|
|
1876
|
-
argument field. If the argument is a pathname, the command
|
|
1877
|
-
is analogous to the "list" command except that data shall be
|
|
1878
|
-
|
|
1879
|
-
|
|
1880
|
-
Postel & Reynolds [Page 33]
|
|
1881
|
-
|
|
1882
|
-
|
|
1883
|
-
|
|
1884
|
-
RFC 959 October 1985
|
|
1885
|
-
File Transfer Protocol
|
|
1886
|
-
|
|
1887
|
-
|
|
1888
|
-
transferred over the control connection. If a partial
|
|
1889
|
-
pathname is given, the server may respond with a list of
|
|
1890
|
-
file names or attributes associated with that specification.
|
|
1891
|
-
If no argument is given, the server should return general
|
|
1892
|
-
status information about the server FTP process. This
|
|
1893
|
-
should include current values of all transfer parameters and
|
|
1894
|
-
the status of connections.
|
|
1895
|
-
|
|
1896
|
-
HELP (HELP)
|
|
1897
|
-
|
|
1898
|
-
This command shall cause the server to send helpful
|
|
1899
|
-
information regarding its implementation status over the
|
|
1900
|
-
control connection to the user. The command may take an
|
|
1901
|
-
argument (e.g., any command name) and return more specific
|
|
1902
|
-
information as a response. The reply is type 211 or 214.
|
|
1903
|
-
It is suggested that HELP be allowed before entering a USER
|
|
1904
|
-
command. The server may use this reply to specify
|
|
1905
|
-
site-dependent parameters, e.g., in response to HELP SITE.
|
|
1906
|
-
|
|
1907
|
-
NOOP (NOOP)
|
|
1908
|
-
|
|
1909
|
-
This command does not affect any parameters or previously
|
|
1910
|
-
entered commands. It specifies no action other than that the
|
|
1911
|
-
server send an OK reply.
|
|
1912
|
-
|
|
1913
|
-
The File Transfer Protocol follows the specifications of the Telnet
|
|
1914
|
-
protocol for all communications over the control connection. Since
|
|
1915
|
-
the language used for Telnet communication may be a negotiated
|
|
1916
|
-
option, all references in the next two sections will be to the
|
|
1917
|
-
"Telnet language" and the corresponding "Telnet end-of-line code".
|
|
1918
|
-
Currently, one may take these to mean NVT-ASCII and <CRLF>. No other
|
|
1919
|
-
specifications of the Telnet protocol will be cited.
|
|
1920
|
-
|
|
1921
|
-
FTP commands are "Telnet strings" terminated by the "Telnet end of
|
|
1922
|
-
line code". The command codes themselves are alphabetic characters
|
|
1923
|
-
terminated by the character <SP> (Space) if parameters follow and
|
|
1924
|
-
Telnet-EOL otherwise. The command codes and the semantics of
|
|
1925
|
-
commands are described in this section; the detailed syntax of
|
|
1926
|
-
commands is specified in the Section on Commands, the reply sequences
|
|
1927
|
-
are discussed in the Section on Sequencing of Commands and Replies,
|
|
1928
|
-
and scenarios illustrating the use of commands are provided in the
|
|
1929
|
-
Section on Typical FTP Scenarios.
|
|
1930
|
-
|
|
1931
|
-
FTP commands may be partitioned as those specifying access-control
|
|
1932
|
-
identifiers, data transfer parameters, or FTP service requests.
|
|
1933
|
-
Certain commands (such as ABOR, STAT, QUIT) may be sent over the
|
|
1934
|
-
control connection while a data transfer is in progress. Some
|
|
1935
|
-
|
|
1936
|
-
|
|
1937
|
-
Postel & Reynolds [Page 34]
|
|
1938
|
-
|
|
1939
|
-
|
|
1940
|
-
|
|
1941
|
-
RFC 959 October 1985
|
|
1942
|
-
File Transfer Protocol
|
|
1943
|
-
|
|
1944
|
-
|
|
1945
|
-
servers may not be able to monitor the control and data connections
|
|
1946
|
-
simultaneously, in which case some special action will be necessary
|
|
1947
|
-
to get the server's attention. The following ordered format is
|
|
1948
|
-
tentatively recommended:
|
|
1949
|
-
|
|
1950
|
-
1. User system inserts the Telnet "Interrupt Process" (IP) signal
|
|
1951
|
-
in the Telnet stream.
|
|
1952
|
-
|
|
1953
|
-
2. User system sends the Telnet "Synch" signal.
|
|
1954
|
-
|
|
1955
|
-
3. User system inserts the command (e.g., ABOR) in the Telnet
|
|
1956
|
-
stream.
|
|
1957
|
-
|
|
1958
|
-
4. Server PI, after receiving "IP", scans the Telnet stream for
|
|
1959
|
-
EXACTLY ONE FTP command.
|
|
1960
|
-
|
|
1961
|
-
(For other servers this may not be necessary but the actions listed
|
|
1962
|
-
above should have no unusual effect.)
|
|
1963
|
-
|
|
1964
|
-
4.2. FTP REPLIES
|
|
1965
|
-
|
|
1966
|
-
Replies to File Transfer Protocol commands are devised to ensure
|
|
1967
|
-
the synchronization of requests and actions in the process of file
|
|
1968
|
-
transfer, and to guarantee that the user process always knows the
|
|
1969
|
-
state of the Server. Every command must generate at least one
|
|
1970
|
-
reply, although there may be more than one; in the latter case,
|
|
1971
|
-
the multiple replies must be easily distinguished. In addition,
|
|
1972
|
-
some commands occur in sequential groups, such as USER, PASS and
|
|
1973
|
-
ACCT, or RNFR and RNTO. The replies show the existence of an
|
|
1974
|
-
intermediate state if all preceding commands have been successful.
|
|
1975
|
-
A failure at any point in the sequence necessitates the repetition
|
|
1976
|
-
of the entire sequence from the beginning.
|
|
1977
|
-
|
|
1978
|
-
The details of the command-reply sequence are made explicit in
|
|
1979
|
-
a set of state diagrams below.
|
|
1980
|
-
|
|
1981
|
-
An FTP reply consists of a three digit number (transmitted as
|
|
1982
|
-
three alphanumeric characters) followed by some text. The number
|
|
1983
|
-
is intended for use by automata to determine what state to enter
|
|
1984
|
-
next; the text is intended for the human user. It is intended
|
|
1985
|
-
that the three digits contain enough encoded information that the
|
|
1986
|
-
user-process (the User-PI) will not need to examine the text and
|
|
1987
|
-
may either discard it or pass it on to the user, as appropriate.
|
|
1988
|
-
In particular, the text may be server-dependent, so there are
|
|
1989
|
-
likely to be varying texts for each reply code.
|
|
1990
|
-
|
|
1991
|
-
A reply is defined to contain the 3-digit code, followed by Space
|
|
1992
|
-
|
|
1993
|
-
|
|
1994
|
-
Postel & Reynolds [Page 35]
|
|
1995
|
-
|
|
1996
|
-
|
|
1997
|
-
|
|
1998
|
-
RFC 959 October 1985
|
|
1999
|
-
File Transfer Protocol
|
|
2000
|
-
|
|
2001
|
-
|
|
2002
|
-
<SP>, followed by one line of text (where some maximum line length
|
|
2003
|
-
has been specified), and terminated by the Telnet end-of-line
|
|
2004
|
-
code. There will be cases however, where the text is longer than
|
|
2005
|
-
a single line. In these cases the complete text must be bracketed
|
|
2006
|
-
so the User-process knows when it may stop reading the reply (i.e.
|
|
2007
|
-
stop processing input on the control connection) and go do other
|
|
2008
|
-
things. This requires a special format on the first line to
|
|
2009
|
-
indicate that more than one line is coming, and another on the
|
|
2010
|
-
last line to designate it as the last. At least one of these must
|
|
2011
|
-
contain the appropriate reply code to indicate the state of the
|
|
2012
|
-
transaction. To satisfy all factions, it was decided that both
|
|
2013
|
-
the first and last line codes should be the same.
|
|
2014
|
-
|
|
2015
|
-
Thus the format for multi-line replies is that the first line
|
|
2016
|
-
will begin with the exact required reply code, followed
|
|
2017
|
-
immediately by a Hyphen, "-" (also known as Minus), followed by
|
|
2018
|
-
text. The last line will begin with the same code, followed
|
|
2019
|
-
immediately by Space <SP>, optionally some text, and the Telnet
|
|
2020
|
-
end-of-line code.
|
|
2021
|
-
|
|
2022
|
-
For example:
|
|
2023
|
-
123-First line
|
|
2024
|
-
Second line
|
|
2025
|
-
234 A line beginning with numbers
|
|
2026
|
-
123 The last line
|
|
2027
|
-
|
|
2028
|
-
The user-process then simply needs to search for the second
|
|
2029
|
-
occurrence of the same reply code, followed by <SP> (Space), at
|
|
2030
|
-
the beginning of a line, and ignore all intermediary lines. If
|
|
2031
|
-
an intermediary line begins with a 3-digit number, the Server
|
|
2032
|
-
must pad the front to avoid confusion.
|
|
2033
|
-
|
|
2034
|
-
This scheme allows standard system routines to be used for
|
|
2035
|
-
reply information (such as for the STAT reply), with
|
|
2036
|
-
"artificial" first and last lines tacked on. In rare cases
|
|
2037
|
-
where these routines are able to generate three digits and a
|
|
2038
|
-
Space at the beginning of any line, the beginning of each
|
|
2039
|
-
text line should be offset by some neutral text, like Space.
|
|
2040
|
-
|
|
2041
|
-
This scheme assumes that multi-line replies may not be nested.
|
|
2042
|
-
|
|
2043
|
-
The three digits of the reply each have a special significance.
|
|
2044
|
-
This is intended to allow a range of very simple to very
|
|
2045
|
-
sophisticated responses by the user-process. The first digit
|
|
2046
|
-
denotes whether the response is good, bad or incomplete.
|
|
2047
|
-
(Referring to the state diagram), an unsophisticated user-process
|
|
2048
|
-
will be able to determine its next action (proceed as planned,
|
|
2049
|
-
|
|
2050
|
-
|
|
2051
|
-
Postel & Reynolds [Page 36]
|
|
2052
|
-
|
|
2053
|
-
|
|
2054
|
-
|
|
2055
|
-
RFC 959 October 1985
|
|
2056
|
-
File Transfer Protocol
|
|
2057
|
-
|
|
2058
|
-
|
|
2059
|
-
redo, retrench, etc.) by simply examining this first digit. A
|
|
2060
|
-
user-process that wants to know approximately what kind of error
|
|
2061
|
-
occurred (e.g. file system error, command syntax error) may
|
|
2062
|
-
examine the second digit, reserving the third digit for the finest
|
|
2063
|
-
gradation of information (e.g., RNTO command without a preceding
|
|
2064
|
-
RNFR).
|
|
2065
|
-
|
|
2066
|
-
There are five values for the first digit of the reply code:
|
|
2067
|
-
|
|
2068
|
-
1yz Positive Preliminary reply
|
|
2069
|
-
|
|
2070
|
-
The requested action is being initiated; expect another
|
|
2071
|
-
reply before proceeding with a new command. (The
|
|
2072
|
-
user-process sending another command before the
|
|
2073
|
-
completion reply would be in violation of protocol; but
|
|
2074
|
-
server-FTP processes should queue any commands that
|
|
2075
|
-
arrive while a preceding command is in progress.) This
|
|
2076
|
-
type of reply can be used to indicate that the command
|
|
2077
|
-
was accepted and the user-process may now pay attention
|
|
2078
|
-
to the data connections, for implementations where
|
|
2079
|
-
simultaneous monitoring is difficult. The server-FTP
|
|
2080
|
-
process may send at most, one 1yz reply per command.
|
|
2081
|
-
|
|
2082
|
-
2yz Positive Completion reply
|
|
2083
|
-
|
|
2084
|
-
The requested action has been successfully completed. A
|
|
2085
|
-
new request may be initiated.
|
|
2086
|
-
|
|
2087
|
-
3yz Positive Intermediate reply
|
|
2088
|
-
|
|
2089
|
-
The command has been accepted, but the requested action
|
|
2090
|
-
is being held in abeyance, pending receipt of further
|
|
2091
|
-
information. The user should send another command
|
|
2092
|
-
specifying this information. This reply is used in
|
|
2093
|
-
command sequence groups.
|
|
2094
|
-
|
|
2095
|
-
4yz Transient Negative Completion reply
|
|
2096
|
-
|
|
2097
|
-
The command was not accepted and the requested action did
|
|
2098
|
-
not take place, but the error condition is temporary and
|
|
2099
|
-
the action may be requested again. The user should
|
|
2100
|
-
return to the beginning of the command sequence, if any.
|
|
2101
|
-
It is difficult to assign a meaning to "transient",
|
|
2102
|
-
particularly when two distinct sites (Server- and
|
|
2103
|
-
User-processes) have to agree on the interpretation.
|
|
2104
|
-
Each reply in the 4yz category might have a slightly
|
|
2105
|
-
different time value, but the intent is that the
|
|
2106
|
-
|
|
2107
|
-
|
|
2108
|
-
Postel & Reynolds [Page 37]
|
|
2109
|
-
|
|
2110
|
-
|
|
2111
|
-
|
|
2112
|
-
RFC 959 October 1985
|
|
2113
|
-
File Transfer Protocol
|
|
2114
|
-
|
|
2115
|
-
|
|
2116
|
-
user-process is encouraged to try again. A rule of thumb
|
|
2117
|
-
in determining if a reply fits into the 4yz or the 5yz
|
|
2118
|
-
(Permanent Negative) category is that replies are 4yz if
|
|
2119
|
-
the commands can be repeated without any change in
|
|
2120
|
-
command form or in properties of the User or Server
|
|
2121
|
-
(e.g., the command is spelled the same with the same
|
|
2122
|
-
arguments used; the user does not change his file access
|
|
2123
|
-
or user name; the server does not put up a new
|
|
2124
|
-
implementation.)
|
|
2125
|
-
|
|
2126
|
-
5yz Permanent Negative Completion reply
|
|
2127
|
-
|
|
2128
|
-
The command was not accepted and the requested action did
|
|
2129
|
-
not take place. The User-process is discouraged from
|
|
2130
|
-
repeating the exact request (in the same sequence). Even
|
|
2131
|
-
some "permanent" error conditions can be corrected, so
|
|
2132
|
-
the human user may want to direct his User-process to
|
|
2133
|
-
reinitiate the command sequence by direct action at some
|
|
2134
|
-
point in the future (e.g., after the spelling has been
|
|
2135
|
-
changed, or the user has altered his directory status.)
|
|
2136
|
-
|
|
2137
|
-
The following function groupings are encoded in the second
|
|
2138
|
-
digit:
|
|
2139
|
-
|
|
2140
|
-
x0z Syntax - These replies refer to syntax errors,
|
|
2141
|
-
syntactically correct commands that don't fit any
|
|
2142
|
-
functional category, unimplemented or superfluous
|
|
2143
|
-
commands.
|
|
2144
|
-
|
|
2145
|
-
x1z Information - These are replies to requests for
|
|
2146
|
-
information, such as status or help.
|
|
2147
|
-
|
|
2148
|
-
x2z Connections - Replies referring to the control and
|
|
2149
|
-
data connections.
|
|
2150
|
-
|
|
2151
|
-
x3z Authentication and accounting - Replies for the login
|
|
2152
|
-
process and accounting procedures.
|
|
2153
|
-
|
|
2154
|
-
x4z Unspecified as yet.
|
|
2155
|
-
|
|
2156
|
-
x5z File system - These replies indicate the status of the
|
|
2157
|
-
Server file system vis-a-vis the requested transfer or
|
|
2158
|
-
other file system action.
|
|
2159
|
-
|
|
2160
|
-
The third digit gives a finer gradation of meaning in each of
|
|
2161
|
-
the function categories, specified by the second digit. The
|
|
2162
|
-
list of replies below will illustrate this. Note that the text
|
|
2163
|
-
|
|
2164
|
-
|
|
2165
|
-
Postel & Reynolds [Page 38]
|
|
2166
|
-
|
|
2167
|
-
|
|
2168
|
-
|
|
2169
|
-
RFC 959 October 1985
|
|
2170
|
-
File Transfer Protocol
|
|
2171
|
-
|
|
2172
|
-
|
|
2173
|
-
associated with each reply is recommended, rather than
|
|
2174
|
-
mandatory, and may even change according to the command with
|
|
2175
|
-
which it is associated. The reply codes, on the other hand,
|
|
2176
|
-
must strictly follow the specifications in the last section;
|
|
2177
|
-
that is, Server implementations should not invent new codes for
|
|
2178
|
-
situations that are only slightly different from the ones
|
|
2179
|
-
described here, but rather should adapt codes already defined.
|
|
2180
|
-
|
|
2181
|
-
A command such as TYPE or ALLO whose successful execution
|
|
2182
|
-
does not offer the user-process any new information will
|
|
2183
|
-
cause a 200 reply to be returned. If the command is not
|
|
2184
|
-
implemented by a particular Server-FTP process because it
|
|
2185
|
-
has no relevance to that computer system, for example ALLO
|
|
2186
|
-
at a TOPS20 site, a Positive Completion reply is still
|
|
2187
|
-
desired so that the simple User-process knows it can proceed
|
|
2188
|
-
with its course of action. A 202 reply is used in this case
|
|
2189
|
-
with, for example, the reply text: "No storage allocation
|
|
2190
|
-
necessary." If, on the other hand, the command requests a
|
|
2191
|
-
non-site-specific action and is unimplemented, the response
|
|
2192
|
-
is 502. A refinement of that is the 504 reply for a command
|
|
2193
|
-
that is implemented, but that requests an unimplemented
|
|
2194
|
-
parameter.
|
|
2195
|
-
|
|
2196
|
-
4.2.1 Reply Codes by Function Groups
|
|
2197
|
-
|
|
2198
|
-
200 Command okay.
|
|
2199
|
-
500 Syntax error, command unrecognized.
|
|
2200
|
-
This may include errors such as command line too long.
|
|
2201
|
-
501 Syntax error in parameters or arguments.
|
|
2202
|
-
202 Command not implemented, superfluous at this site.
|
|
2203
|
-
502 Command not implemented.
|
|
2204
|
-
503 Bad sequence of commands.
|
|
2205
|
-
504 Command not implemented for that parameter.
|
|
2206
|
-
|
|
2207
|
-
|
|
2208
|
-
|
|
2209
|
-
|
|
2210
|
-
|
|
2211
|
-
|
|
2212
|
-
|
|
2213
|
-
|
|
2214
|
-
|
|
2215
|
-
|
|
2216
|
-
|
|
2217
|
-
|
|
2218
|
-
|
|
2219
|
-
|
|
2220
|
-
|
|
2221
|
-
|
|
2222
|
-
Postel & Reynolds [Page 39]
|
|
2223
|
-
|
|
2224
|
-
|
|
2225
|
-
|
|
2226
|
-
RFC 959 October 1985
|
|
2227
|
-
File Transfer Protocol
|
|
2228
|
-
|
|
2229
|
-
|
|
2230
|
-
110 Restart marker reply.
|
|
2231
|
-
In this case, the text is exact and not left to the
|
|
2232
|
-
particular implementation; it must read:
|
|
2233
|
-
MARK yyyy = mmmm
|
|
2234
|
-
Where yyyy is User-process data stream marker, and mmmm
|
|
2235
|
-
server's equivalent marker (note the spaces between markers
|
|
2236
|
-
and "=").
|
|
2237
|
-
211 System status, or system help reply.
|
|
2238
|
-
212 Directory status.
|
|
2239
|
-
213 File status.
|
|
2240
|
-
214 Help message.
|
|
2241
|
-
On how to use the server or the meaning of a particular
|
|
2242
|
-
non-standard command. This reply is useful only to the
|
|
2243
|
-
human user.
|
|
2244
|
-
215 NAME system type.
|
|
2245
|
-
Where NAME is an official system name from the list in the
|
|
2246
|
-
Assigned Numbers document.
|
|
2247
|
-
|
|
2248
|
-
120 Service ready in nnn minutes.
|
|
2249
|
-
220 Service ready for new user.
|
|
2250
|
-
221 Service closing control connection.
|
|
2251
|
-
Logged out if appropriate.
|
|
2252
|
-
421 Service not available, closing control connection.
|
|
2253
|
-
This may be a reply to any command if the service knows it
|
|
2254
|
-
must shut down.
|
|
2255
|
-
125 Data connection already open; transfer starting.
|
|
2256
|
-
225 Data connection open; no transfer in progress.
|
|
2257
|
-
425 Can't open data connection.
|
|
2258
|
-
226 Closing data connection.
|
|
2259
|
-
Requested file action successful (for example, file
|
|
2260
|
-
transfer or file abort).
|
|
2261
|
-
426 Connection closed; transfer aborted.
|
|
2262
|
-
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
|
|
2263
|
-
|
|
2264
|
-
230 User logged in, proceed.
|
|
2265
|
-
530 Not logged in.
|
|
2266
|
-
331 User name okay, need password.
|
|
2267
|
-
332 Need account for login.
|
|
2268
|
-
532 Need account for storing files.
|
|
2269
|
-
|
|
2270
|
-
|
|
2271
|
-
|
|
2272
|
-
|
|
2273
|
-
|
|
2274
|
-
|
|
2275
|
-
|
|
2276
|
-
|
|
2277
|
-
|
|
2278
|
-
|
|
2279
|
-
Postel & Reynolds [Page 40]
|
|
2280
|
-
|
|
2281
|
-
|
|
2282
|
-
|
|
2283
|
-
RFC 959 October 1985
|
|
2284
|
-
File Transfer Protocol
|
|
2285
|
-
|
|
2286
|
-
|
|
2287
|
-
150 File status okay; about to open data connection.
|
|
2288
|
-
250 Requested file action okay, completed.
|
|
2289
|
-
257 "PATHNAME" created.
|
|
2290
|
-
350 Requested file action pending further information.
|
|
2291
|
-
450 Requested file action not taken.
|
|
2292
|
-
File unavailable (e.g., file busy).
|
|
2293
|
-
550 Requested action not taken.
|
|
2294
|
-
File unavailable (e.g., file not found, no access).
|
|
2295
|
-
451 Requested action aborted. Local error in processing.
|
|
2296
|
-
551 Requested action aborted. Page type unknown.
|
|
2297
|
-
452 Requested action not taken.
|
|
2298
|
-
Insufficient storage space in system.
|
|
2299
|
-
552 Requested file action aborted.
|
|
2300
|
-
Exceeded storage allocation (for current directory or
|
|
2301
|
-
dataset).
|
|
2302
|
-
553 Requested action not taken.
|
|
2303
|
-
File name not allowed.
|
|
2304
|
-
|
|
2305
|
-
|
|
2306
|
-
4.2.2 Numeric Order List of Reply Codes
|
|
2307
|
-
|
|
2308
|
-
110 Restart marker reply.
|
|
2309
|
-
In this case, the text is exact and not left to the
|
|
2310
|
-
particular implementation; it must read:
|
|
2311
|
-
MARK yyyy = mmmm
|
|
2312
|
-
Where yyyy is User-process data stream marker, and mmmm
|
|
2313
|
-
server's equivalent marker (note the spaces between markers
|
|
2314
|
-
and "=").
|
|
2315
|
-
120 Service ready in nnn minutes.
|
|
2316
|
-
125 Data connection already open; transfer starting.
|
|
2317
|
-
150 File status okay; about to open data connection.
|
|
2318
|
-
|
|
2319
|
-
|
|
2320
|
-
|
|
2321
|
-
|
|
2322
|
-
|
|
2323
|
-
|
|
2324
|
-
|
|
2325
|
-
|
|
2326
|
-
|
|
2327
|
-
|
|
2328
|
-
|
|
2329
|
-
|
|
2330
|
-
|
|
2331
|
-
|
|
2332
|
-
|
|
2333
|
-
|
|
2334
|
-
|
|
2335
|
-
|
|
2336
|
-
Postel & Reynolds [Page 41]
|
|
2337
|
-
|
|
2338
|
-
|
|
2339
|
-
|
|
2340
|
-
RFC 959 October 1985
|
|
2341
|
-
File Transfer Protocol
|
|
2342
|
-
|
|
2343
|
-
|
|
2344
|
-
200 Command okay.
|
|
2345
|
-
202 Command not implemented, superfluous at this site.
|
|
2346
|
-
211 System status, or system help reply.
|
|
2347
|
-
212 Directory status.
|
|
2348
|
-
213 File status.
|
|
2349
|
-
214 Help message.
|
|
2350
|
-
On how to use the server or the meaning of a particular
|
|
2351
|
-
non-standard command. This reply is useful only to the
|
|
2352
|
-
human user.
|
|
2353
|
-
215 NAME system type.
|
|
2354
|
-
Where NAME is an official system name from the list in the
|
|
2355
|
-
Assigned Numbers document.
|
|
2356
|
-
220 Service ready for new user.
|
|
2357
|
-
221 Service closing control connection.
|
|
2358
|
-
Logged out if appropriate.
|
|
2359
|
-
225 Data connection open; no transfer in progress.
|
|
2360
|
-
226 Closing data connection.
|
|
2361
|
-
Requested file action successful (for example, file
|
|
2362
|
-
transfer or file abort).
|
|
2363
|
-
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
|
|
2364
|
-
230 User logged in, proceed.
|
|
2365
|
-
250 Requested file action okay, completed.
|
|
2366
|
-
257 "PATHNAME" created.
|
|
2367
|
-
|
|
2368
|
-
331 User name okay, need password.
|
|
2369
|
-
332 Need account for login.
|
|
2370
|
-
350 Requested file action pending further information.
|
|
2371
|
-
|
|
2372
|
-
421 Service not available, closing control connection.
|
|
2373
|
-
This may be a reply to any command if the service knows it
|
|
2374
|
-
must shut down.
|
|
2375
|
-
425 Can't open data connection.
|
|
2376
|
-
426 Connection closed; transfer aborted.
|
|
2377
|
-
450 Requested file action not taken.
|
|
2378
|
-
File unavailable (e.g., file busy).
|
|
2379
|
-
451 Requested action aborted: local error in processing.
|
|
2380
|
-
452 Requested action not taken.
|
|
2381
|
-
Insufficient storage space in system.
|
|
2382
|
-
|
|
2383
|
-
|
|
2384
|
-
|
|
2385
|
-
|
|
2386
|
-
|
|
2387
|
-
|
|
2388
|
-
|
|
2389
|
-
|
|
2390
|
-
|
|
2391
|
-
|
|
2392
|
-
|
|
2393
|
-
Postel & Reynolds [Page 42]
|
|
2394
|
-
|
|
2395
|
-
|
|
2396
|
-
|
|
2397
|
-
RFC 959 October 1985
|
|
2398
|
-
File Transfer Protocol
|
|
2399
|
-
|
|
2400
|
-
|
|
2401
|
-
500 Syntax error, command unrecognized.
|
|
2402
|
-
This may include errors such as command line too long.
|
|
2403
|
-
501 Syntax error in parameters or arguments.
|
|
2404
|
-
502 Command not implemented.
|
|
2405
|
-
503 Bad sequence of commands.
|
|
2406
|
-
504 Command not implemented for that parameter.
|
|
2407
|
-
530 Not logged in.
|
|
2408
|
-
532 Need account for storing files.
|
|
2409
|
-
550 Requested action not taken.
|
|
2410
|
-
File unavailable (e.g., file not found, no access).
|
|
2411
|
-
551 Requested action aborted: page type unknown.
|
|
2412
|
-
552 Requested file action aborted.
|
|
2413
|
-
Exceeded storage allocation (for current directory or
|
|
2414
|
-
dataset).
|
|
2415
|
-
553 Requested action not taken.
|
|
2416
|
-
File name not allowed.
|
|
2417
|
-
|
|
2418
|
-
|
|
2419
|
-
5. DECLARATIVE SPECIFICATIONS
|
|
2420
|
-
|
|
2421
|
-
5.1. MINIMUM IMPLEMENTATION
|
|
2422
|
-
|
|
2423
|
-
In order to make FTP workable without needless error messages, the
|
|
2424
|
-
following minimum implementation is required for all servers:
|
|
2425
|
-
|
|
2426
|
-
TYPE - ASCII Non-print
|
|
2427
|
-
MODE - Stream
|
|
2428
|
-
STRUCTURE - File, Record
|
|
2429
|
-
COMMANDS - USER, QUIT, PORT,
|
|
2430
|
-
TYPE, MODE, STRU,
|
|
2431
|
-
for the default values
|
|
2432
|
-
RETR, STOR,
|
|
2433
|
-
NOOP.
|
|
2434
|
-
|
|
2435
|
-
The default values for transfer parameters are:
|
|
2436
|
-
|
|
2437
|
-
TYPE - ASCII Non-print
|
|
2438
|
-
MODE - Stream
|
|
2439
|
-
STRU - File
|
|
2440
|
-
|
|
2441
|
-
All hosts must accept the above as the standard defaults.
|
|
2442
|
-
|
|
2443
|
-
|
|
2444
|
-
|
|
2445
|
-
|
|
2446
|
-
|
|
2447
|
-
|
|
2448
|
-
|
|
2449
|
-
|
|
2450
|
-
Postel & Reynolds [Page 43]
|
|
2451
|
-
|
|
2452
|
-
|
|
2453
|
-
|
|
2454
|
-
RFC 959 October 1985
|
|
2455
|
-
File Transfer Protocol
|
|
2456
|
-
|
|
2457
|
-
|
|
2458
|
-
5.2. CONNECTIONS
|
|
2459
|
-
|
|
2460
|
-
The server protocol interpreter shall "listen" on Port L. The
|
|
2461
|
-
user or user protocol interpreter shall initiate the full-duplex
|
|
2462
|
-
control connection. Server- and user- processes should follow the
|
|
2463
|
-
conventions of the Telnet protocol as specified in the
|
|
2464
|
-
ARPA-Internet Protocol Handbook [1]. Servers are under no
|
|
2465
|
-
obligation to provide for editing of command lines and may require
|
|
2466
|
-
that it be done in the user host. The control connection shall be
|
|
2467
|
-
closed by the server at the user's request after all transfers and
|
|
2468
|
-
replies are completed.
|
|
2469
|
-
|
|
2470
|
-
The user-DTP must "listen" on the specified data port; this may be
|
|
2471
|
-
the default user port (U) or a port specified in the PORT command.
|
|
2472
|
-
The server shall initiate the data connection from his own default
|
|
2473
|
-
data port (L-1) using the specified user data port. The direction
|
|
2474
|
-
of the transfer and the port used will be determined by the FTP
|
|
2475
|
-
service command.
|
|
2476
|
-
|
|
2477
|
-
Note that all FTP implementation must support data transfer using
|
|
2478
|
-
the default port, and that only the USER-PI may initiate the use
|
|
2479
|
-
of non-default ports.
|
|
2480
|
-
|
|
2481
|
-
When data is to be transferred between two servers, A and B (refer
|
|
2482
|
-
to Figure 2), the user-PI, C, sets up control connections with
|
|
2483
|
-
both server-PI's. One of the servers, say A, is then sent a PASV
|
|
2484
|
-
command telling him to "listen" on his data port rather than
|
|
2485
|
-
initiate a connection when he receives a transfer service command.
|
|
2486
|
-
When the user-PI receives an acknowledgment to the PASV command,
|
|
2487
|
-
which includes the identity of the host and port being listened
|
|
2488
|
-
on, the user-PI then sends A's port, a, to B in a PORT command; a
|
|
2489
|
-
reply is returned. The user-PI may then send the corresponding
|
|
2490
|
-
service commands to A and B. Server B initiates the connection
|
|
2491
|
-
and the transfer proceeds. The command-reply sequence is listed
|
|
2492
|
-
below where the messages are vertically synchronous but
|
|
2493
|
-
horizontally asynchronous:
|
|
2494
|
-
|
|
2495
|
-
|
|
2496
|
-
|
|
2497
|
-
|
|
2498
|
-
|
|
2499
|
-
|
|
2500
|
-
|
|
2501
|
-
|
|
2502
|
-
|
|
2503
|
-
|
|
2504
|
-
|
|
2505
|
-
|
|
2506
|
-
|
|
2507
|
-
Postel & Reynolds [Page 44]
|
|
2508
|
-
|
|
2509
|
-
|
|
2510
|
-
|
|
2511
|
-
RFC 959 October 1985
|
|
2512
|
-
File Transfer Protocol
|
|
2513
|
-
|
|
2514
|
-
|
|
2515
|
-
User-PI - Server A User-PI - Server B
|
|
2516
|
-
------------------ ------------------
|
|
2517
|
-
|
|
2518
|
-
C->A : Connect C->B : Connect
|
|
2519
|
-
C->A : PASV
|
|
2520
|
-
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
|
|
2521
|
-
C->B : PORT A1,A2,A3,A4,a1,a2
|
|
2522
|
-
B->C : 200 Okay
|
|
2523
|
-
C->A : STOR C->B : RETR
|
|
2524
|
-
B->A : Connect to HOST-A, PORT-a
|
|
2525
|
-
|
|
2526
|
-
Figure 3
|
|
2527
|
-
|
|
2528
|
-
The data connection shall be closed by the server under the
|
|
2529
|
-
conditions described in the Section on Establishing Data
|
|
2530
|
-
Connections. If the data connection is to be closed following a
|
|
2531
|
-
data transfer where closing the connection is not required to
|
|
2532
|
-
indicate the end-of-file, the server must do so immediately.
|
|
2533
|
-
Waiting until after a new transfer command is not permitted
|
|
2534
|
-
because the user-process will have already tested the data
|
|
2535
|
-
connection to see if it needs to do a "listen"; (remember that the
|
|
2536
|
-
user must "listen" on a closed data port BEFORE sending the
|
|
2537
|
-
transfer request). To prevent a race condition here, the server
|
|
2538
|
-
sends a reply (226) after closing the data connection (or if the
|
|
2539
|
-
connection is left open, a "file transfer completed" reply (250)
|
|
2540
|
-
and the user-PI should wait for one of these replies before
|
|
2541
|
-
issuing a new transfer command).
|
|
2542
|
-
|
|
2543
|
-
Any time either the user or server see that the connection is
|
|
2544
|
-
being closed by the other side, it should promptly read any
|
|
2545
|
-
remaining data queued on the connection and issue the close on its
|
|
2546
|
-
own side.
|
|
2547
|
-
|
|
2548
|
-
5.3. COMMANDS
|
|
2549
|
-
|
|
2550
|
-
The commands are Telnet character strings transmitted over the
|
|
2551
|
-
control connections as described in the Section on FTP Commands.
|
|
2552
|
-
The command functions and semantics are described in the Section
|
|
2553
|
-
on Access Control Commands, Transfer Parameter Commands, FTP
|
|
2554
|
-
Service Commands, and Miscellaneous Commands. The command syntax
|
|
2555
|
-
is specified here.
|
|
2556
|
-
|
|
2557
|
-
The commands begin with a command code followed by an argument
|
|
2558
|
-
field. The command codes are four or fewer alphabetic characters.
|
|
2559
|
-
Upper and lower case alphabetic characters are to be treated
|
|
2560
|
-
identically. Thus, any of the following may represent the
|
|
2561
|
-
retrieve command:
|
|
2562
|
-
|
|
2563
|
-
|
|
2564
|
-
Postel & Reynolds [Page 45]
|
|
2565
|
-
|
|
2566
|
-
|
|
2567
|
-
|
|
2568
|
-
RFC 959 October 1985
|
|
2569
|
-
File Transfer Protocol
|
|
2570
|
-
|
|
2571
|
-
|
|
2572
|
-
RETR Retr retr ReTr rETr
|
|
2573
|
-
|
|
2574
|
-
This also applies to any symbols representing parameter values,
|
|
2575
|
-
such as A or a for ASCII TYPE. The command codes and the argument
|
|
2576
|
-
fields are separated by one or more spaces.
|
|
2577
|
-
|
|
2578
|
-
The argument field consists of a variable length character string
|
|
2579
|
-
ending with the character sequence <CRLF> (Carriage Return, Line
|
|
2580
|
-
Feed) for NVT-ASCII representation; for other negotiated languages
|
|
2581
|
-
a different end of line character might be used. It should be
|
|
2582
|
-
noted that the server is to take no action until the end of line
|
|
2583
|
-
code is received.
|
|
2584
|
-
|
|
2585
|
-
The syntax is specified below in NVT-ASCII. All characters in the
|
|
2586
|
-
argument field are ASCII characters including any ASCII
|
|
2587
|
-
represented decimal integers. Square brackets denote an optional
|
|
2588
|
-
argument field. If the option is not taken, the appropriate
|
|
2589
|
-
default is implied.
|
|
2590
|
-
|
|
2591
|
-
|
|
2592
|
-
|
|
2593
|
-
|
|
2594
|
-
|
|
2595
|
-
|
|
2596
|
-
|
|
2597
|
-
|
|
2598
|
-
|
|
2599
|
-
|
|
2600
|
-
|
|
2601
|
-
|
|
2602
|
-
|
|
2603
|
-
|
|
2604
|
-
|
|
2605
|
-
|
|
2606
|
-
|
|
2607
|
-
|
|
2608
|
-
|
|
2609
|
-
|
|
2610
|
-
|
|
2611
|
-
|
|
2612
|
-
|
|
2613
|
-
|
|
2614
|
-
|
|
2615
|
-
|
|
2616
|
-
|
|
2617
|
-
|
|
2618
|
-
|
|
2619
|
-
|
|
2620
|
-
|
|
2621
|
-
Postel & Reynolds [Page 46]
|
|
2622
|
-
|
|
2623
|
-
|
|
2624
|
-
|
|
2625
|
-
RFC 959 October 1985
|
|
2626
|
-
File Transfer Protocol
|
|
2627
|
-
|
|
2628
|
-
|
|
2629
|
-
5.3.1. FTP COMMANDS
|
|
2630
|
-
|
|
2631
|
-
The following are the FTP commands:
|
|
2632
|
-
|
|
2633
|
-
USER <SP> <username> <CRLF>
|
|
2634
|
-
PASS <SP> <password> <CRLF>
|
|
2635
|
-
ACCT <SP> <account-information> <CRLF>
|
|
2636
|
-
CWD <SP> <pathname> <CRLF>
|
|
2637
|
-
CDUP <CRLF>
|
|
2638
|
-
SMNT <SP> <pathname> <CRLF>
|
|
2639
|
-
QUIT <CRLF>
|
|
2640
|
-
REIN <CRLF>
|
|
2641
|
-
PORT <SP> <host-port> <CRLF>
|
|
2642
|
-
PASV <CRLF>
|
|
2643
|
-
TYPE <SP> <type-code> <CRLF>
|
|
2644
|
-
STRU <SP> <structure-code> <CRLF>
|
|
2645
|
-
MODE <SP> <mode-code> <CRLF>
|
|
2646
|
-
RETR <SP> <pathname> <CRLF>
|
|
2647
|
-
STOR <SP> <pathname> <CRLF>
|
|
2648
|
-
STOU <CRLF>
|
|
2649
|
-
APPE <SP> <pathname> <CRLF>
|
|
2650
|
-
ALLO <SP> <decimal-integer>
|
|
2651
|
-
[<SP> R <SP> <decimal-integer>] <CRLF>
|
|
2652
|
-
REST <SP> <marker> <CRLF>
|
|
2653
|
-
RNFR <SP> <pathname> <CRLF>
|
|
2654
|
-
RNTO <SP> <pathname> <CRLF>
|
|
2655
|
-
ABOR <CRLF>
|
|
2656
|
-
DELE <SP> <pathname> <CRLF>
|
|
2657
|
-
RMD <SP> <pathname> <CRLF>
|
|
2658
|
-
MKD <SP> <pathname> <CRLF>
|
|
2659
|
-
PWD <CRLF>
|
|
2660
|
-
LIST [<SP> <pathname>] <CRLF>
|
|
2661
|
-
NLST [<SP> <pathname>] <CRLF>
|
|
2662
|
-
SITE <SP> <string> <CRLF>
|
|
2663
|
-
SYST <CRLF>
|
|
2664
|
-
STAT [<SP> <pathname>] <CRLF>
|
|
2665
|
-
HELP [<SP> <string>] <CRLF>
|
|
2666
|
-
NOOP <CRLF>
|
|
2667
|
-
|
|
2668
|
-
|
|
2669
|
-
|
|
2670
|
-
|
|
2671
|
-
|
|
2672
|
-
|
|
2673
|
-
|
|
2674
|
-
|
|
2675
|
-
|
|
2676
|
-
|
|
2677
|
-
|
|
2678
|
-
Postel & Reynolds [Page 47]
|
|
2679
|
-
|
|
2680
|
-
|
|
2681
|
-
|
|
2682
|
-
RFC 959 October 1985
|
|
2683
|
-
File Transfer Protocol
|
|
2684
|
-
|
|
2685
|
-
|
|
2686
|
-
5.3.2. FTP COMMAND ARGUMENTS
|
|
2687
|
-
|
|
2688
|
-
The syntax of the above argument fields (using BNF notation
|
|
2689
|
-
where applicable) is:
|
|
2690
|
-
|
|
2691
|
-
<username> ::= <string>
|
|
2692
|
-
<password> ::= <string>
|
|
2693
|
-
<account-information> ::= <string>
|
|
2694
|
-
<string> ::= <char> | <char><string>
|
|
2695
|
-
<char> ::= any of the 128 ASCII characters except <CR> and
|
|
2696
|
-
<LF>
|
|
2697
|
-
<marker> ::= <pr-string>
|
|
2698
|
-
<pr-string> ::= <pr-char> | <pr-char><pr-string>
|
|
2699
|
-
<pr-char> ::= printable characters, any
|
|
2700
|
-
ASCII code 33 through 126
|
|
2701
|
-
<byte-size> ::= <number>
|
|
2702
|
-
<host-port> ::= <host-number>,<port-number>
|
|
2703
|
-
<host-number> ::= <number>,<number>,<number>,<number>
|
|
2704
|
-
<port-number> ::= <number>,<number>
|
|
2705
|
-
<number> ::= any decimal integer 1 through 255
|
|
2706
|
-
<form-code> ::= N | T | C
|
|
2707
|
-
<type-code> ::= A [<sp> <form-code>]
|
|
2708
|
-
| E [<sp> <form-code>]
|
|
2709
|
-
| I
|
|
2710
|
-
| L <sp> <byte-size>
|
|
2711
|
-
<structure-code> ::= F | R | P
|
|
2712
|
-
<mode-code> ::= S | B | C
|
|
2713
|
-
<pathname> ::= <string>
|
|
2714
|
-
<decimal-integer> ::= any decimal integer
|
|
2715
|
-
|
|
2716
|
-
|
|
2717
|
-
|
|
2718
|
-
|
|
2719
|
-
|
|
2720
|
-
|
|
2721
|
-
|
|
2722
|
-
|
|
2723
|
-
|
|
2724
|
-
|
|
2725
|
-
|
|
2726
|
-
|
|
2727
|
-
|
|
2728
|
-
|
|
2729
|
-
|
|
2730
|
-
|
|
2731
|
-
|
|
2732
|
-
|
|
2733
|
-
|
|
2734
|
-
|
|
2735
|
-
Postel & Reynolds [Page 48]
|
|
2736
|
-
|
|
2737
|
-
|
|
2738
|
-
|
|
2739
|
-
RFC 959 October 1985
|
|
2740
|
-
File Transfer Protocol
|
|
2741
|
-
|
|
2742
|
-
|
|
2743
|
-
5.4. SEQUENCING OF COMMANDS AND REPLIES
|
|
2744
|
-
|
|
2745
|
-
The communication between the user and server is intended to be an
|
|
2746
|
-
alternating dialogue. As such, the user issues an FTP command and
|
|
2747
|
-
the server responds with a prompt primary reply. The user should
|
|
2748
|
-
wait for this initial primary success or failure response before
|
|
2749
|
-
sending further commands.
|
|
2750
|
-
|
|
2751
|
-
Certain commands require a second reply for which the user should
|
|
2752
|
-
also wait. These replies may, for example, report on the progress
|
|
2753
|
-
or completion of file transfer or the closing of the data
|
|
2754
|
-
connection. They are secondary replies to file transfer commands.
|
|
2755
|
-
|
|
2756
|
-
One important group of informational replies is the connection
|
|
2757
|
-
greetings. Under normal circumstances, a server will send a 220
|
|
2758
|
-
reply, "awaiting input", when the connection is completed. The
|
|
2759
|
-
user should wait for this greeting message before sending any
|
|
2760
|
-
commands. If the server is unable to accept input right away, a
|
|
2761
|
-
120 "expected delay" reply should be sent immediately and a 220
|
|
2762
|
-
reply when ready. The user will then know not to hang up if there
|
|
2763
|
-
is a delay.
|
|
2764
|
-
|
|
2765
|
-
Spontaneous Replies
|
|
2766
|
-
|
|
2767
|
-
Sometimes "the system" spontaneously has a message to be sent
|
|
2768
|
-
to a user (usually all users). For example, "System going down
|
|
2769
|
-
in 15 minutes". There is no provision in FTP for such
|
|
2770
|
-
spontaneous information to be sent from the server to the user.
|
|
2771
|
-
It is recommended that such information be queued in the
|
|
2772
|
-
server-PI and delivered to the user-PI in the next reply
|
|
2773
|
-
(possibly making it a multi-line reply).
|
|
2774
|
-
|
|
2775
|
-
The table below lists alternative success and failure replies for
|
|
2776
|
-
each command. These must be strictly adhered to; a server may
|
|
2777
|
-
substitute text in the replies, but the meaning and action implied
|
|
2778
|
-
by the code numbers and by the specific command reply sequence
|
|
2779
|
-
cannot be altered.
|
|
2780
|
-
|
|
2781
|
-
Command-Reply Sequences
|
|
2782
|
-
|
|
2783
|
-
In this section, the command-reply sequence is presented. Each
|
|
2784
|
-
command is listed with its possible replies; command groups are
|
|
2785
|
-
listed together. Preliminary replies are listed first (with
|
|
2786
|
-
their succeeding replies indented and under them), then
|
|
2787
|
-
positive and negative completion, and finally intermediary
|
|
2788
|
-
|
|
2789
|
-
|
|
2790
|
-
|
|
2791
|
-
|
|
2792
|
-
Postel & Reynolds [Page 49]
|
|
2793
|
-
|
|
2794
|
-
|
|
2795
|
-
|
|
2796
|
-
RFC 959 October 1985
|
|
2797
|
-
File Transfer Protocol
|
|
2798
|
-
|
|
2799
|
-
|
|
2800
|
-
replies with the remaining commands from the sequence
|
|
2801
|
-
following. This listing forms the basis for the state
|
|
2802
|
-
diagrams, which will be presented separately.
|
|
2803
|
-
|
|
2804
|
-
Connection Establishment
|
|
2805
|
-
120
|
|
2806
|
-
220
|
|
2807
|
-
220
|
|
2808
|
-
421
|
|
2809
|
-
Login
|
|
2810
|
-
USER
|
|
2811
|
-
230
|
|
2812
|
-
530
|
|
2813
|
-
500, 501, 421
|
|
2814
|
-
331, 332
|
|
2815
|
-
PASS
|
|
2816
|
-
230
|
|
2817
|
-
202
|
|
2818
|
-
530
|
|
2819
|
-
500, 501, 503, 421
|
|
2820
|
-
332
|
|
2821
|
-
ACCT
|
|
2822
|
-
230
|
|
2823
|
-
202
|
|
2824
|
-
530
|
|
2825
|
-
500, 501, 503, 421
|
|
2826
|
-
CWD
|
|
2827
|
-
250
|
|
2828
|
-
500, 501, 502, 421, 530, 550
|
|
2829
|
-
CDUP
|
|
2830
|
-
200
|
|
2831
|
-
500, 501, 502, 421, 530, 550
|
|
2832
|
-
SMNT
|
|
2833
|
-
202, 250
|
|
2834
|
-
500, 501, 502, 421, 530, 550
|
|
2835
|
-
Logout
|
|
2836
|
-
REIN
|
|
2837
|
-
120
|
|
2838
|
-
220
|
|
2839
|
-
220
|
|
2840
|
-
421
|
|
2841
|
-
500, 502
|
|
2842
|
-
QUIT
|
|
2843
|
-
221
|
|
2844
|
-
500
|
|
2845
|
-
|
|
2846
|
-
|
|
2847
|
-
|
|
2848
|
-
|
|
2849
|
-
Postel & Reynolds [Page 50]
|
|
2850
|
-
|
|
2851
|
-
|
|
2852
|
-
|
|
2853
|
-
RFC 959 October 1985
|
|
2854
|
-
File Transfer Protocol
|
|
2855
|
-
|
|
2856
|
-
|
|
2857
|
-
Transfer parameters
|
|
2858
|
-
PORT
|
|
2859
|
-
200
|
|
2860
|
-
500, 501, 421, 530
|
|
2861
|
-
PASV
|
|
2862
|
-
227
|
|
2863
|
-
500, 501, 502, 421, 530
|
|
2864
|
-
MODE
|
|
2865
|
-
200
|
|
2866
|
-
500, 501, 504, 421, 530
|
|
2867
|
-
TYPE
|
|
2868
|
-
200
|
|
2869
|
-
500, 501, 504, 421, 530
|
|
2870
|
-
STRU
|
|
2871
|
-
200
|
|
2872
|
-
500, 501, 504, 421, 530
|
|
2873
|
-
File action commands
|
|
2874
|
-
ALLO
|
|
2875
|
-
200
|
|
2876
|
-
202
|
|
2877
|
-
500, 501, 504, 421, 530
|
|
2878
|
-
REST
|
|
2879
|
-
500, 501, 502, 421, 530
|
|
2880
|
-
350
|
|
2881
|
-
STOR
|
|
2882
|
-
125, 150
|
|
2883
|
-
(110)
|
|
2884
|
-
226, 250
|
|
2885
|
-
425, 426, 451, 551, 552
|
|
2886
|
-
532, 450, 452, 553
|
|
2887
|
-
500, 501, 421, 530
|
|
2888
|
-
STOU
|
|
2889
|
-
125, 150
|
|
2890
|
-
(110)
|
|
2891
|
-
226, 250
|
|
2892
|
-
425, 426, 451, 551, 552
|
|
2893
|
-
532, 450, 452, 553
|
|
2894
|
-
500, 501, 421, 530
|
|
2895
|
-
RETR
|
|
2896
|
-
125, 150
|
|
2897
|
-
(110)
|
|
2898
|
-
226, 250
|
|
2899
|
-
425, 426, 451
|
|
2900
|
-
450, 550
|
|
2901
|
-
500, 501, 421, 530
|
|
2902
|
-
|
|
2903
|
-
|
|
2904
|
-
|
|
2905
|
-
|
|
2906
|
-
Postel & Reynolds [Page 51]
|
|
2907
|
-
|
|
2908
|
-
|
|
2909
|
-
|
|
2910
|
-
RFC 959 October 1985
|
|
2911
|
-
File Transfer Protocol
|
|
2912
|
-
|
|
2913
|
-
|
|
2914
|
-
LIST
|
|
2915
|
-
125, 150
|
|
2916
|
-
226, 250
|
|
2917
|
-
425, 426, 451
|
|
2918
|
-
450
|
|
2919
|
-
500, 501, 502, 421, 530
|
|
2920
|
-
NLST
|
|
2921
|
-
125, 150
|
|
2922
|
-
226, 250
|
|
2923
|
-
425, 426, 451
|
|
2924
|
-
450
|
|
2925
|
-
500, 501, 502, 421, 530
|
|
2926
|
-
APPE
|
|
2927
|
-
125, 150
|
|
2928
|
-
(110)
|
|
2929
|
-
226, 250
|
|
2930
|
-
425, 426, 451, 551, 552
|
|
2931
|
-
532, 450, 550, 452, 553
|
|
2932
|
-
500, 501, 502, 421, 530
|
|
2933
|
-
RNFR
|
|
2934
|
-
450, 550
|
|
2935
|
-
500, 501, 502, 421, 530
|
|
2936
|
-
350
|
|
2937
|
-
RNTO
|
|
2938
|
-
250
|
|
2939
|
-
532, 553
|
|
2940
|
-
500, 501, 502, 503, 421, 530
|
|
2941
|
-
DELE
|
|
2942
|
-
250
|
|
2943
|
-
450, 550
|
|
2944
|
-
500, 501, 502, 421, 530
|
|
2945
|
-
RMD
|
|
2946
|
-
250
|
|
2947
|
-
500, 501, 502, 421, 530, 550
|
|
2948
|
-
MKD
|
|
2949
|
-
257
|
|
2950
|
-
500, 501, 502, 421, 530, 550
|
|
2951
|
-
PWD
|
|
2952
|
-
257
|
|
2953
|
-
500, 501, 502, 421, 550
|
|
2954
|
-
ABOR
|
|
2955
|
-
225, 226
|
|
2956
|
-
500, 501, 502, 421
|
|
2957
|
-
|
|
2958
|
-
|
|
2959
|
-
|
|
2960
|
-
|
|
2961
|
-
|
|
2962
|
-
|
|
2963
|
-
Postel & Reynolds [Page 52]
|
|
2964
|
-
|
|
2965
|
-
|
|
2966
|
-
|
|
2967
|
-
RFC 959 October 1985
|
|
2968
|
-
File Transfer Protocol
|
|
2969
|
-
|
|
2970
|
-
|
|
2971
|
-
Informational commands
|
|
2972
|
-
SYST
|
|
2973
|
-
215
|
|
2974
|
-
500, 501, 502, 421
|
|
2975
|
-
STAT
|
|
2976
|
-
211, 212, 213
|
|
2977
|
-
450
|
|
2978
|
-
500, 501, 502, 421, 530
|
|
2979
|
-
HELP
|
|
2980
|
-
211, 214
|
|
2981
|
-
500, 501, 502, 421
|
|
2982
|
-
Miscellaneous commands
|
|
2983
|
-
SITE
|
|
2984
|
-
200
|
|
2985
|
-
202
|
|
2986
|
-
500, 501, 530
|
|
2987
|
-
NOOP
|
|
2988
|
-
200
|
|
2989
|
-
500 421
|
|
2990
|
-
|
|
2991
|
-
|
|
2992
|
-
|
|
2993
|
-
|
|
2994
|
-
|
|
2995
|
-
|
|
2996
|
-
|
|
2997
|
-
|
|
2998
|
-
|
|
2999
|
-
|
|
3000
|
-
|
|
3001
|
-
|
|
3002
|
-
|
|
3003
|
-
|
|
3004
|
-
|
|
3005
|
-
|
|
3006
|
-
|
|
3007
|
-
|
|
3008
|
-
|
|
3009
|
-
|
|
3010
|
-
|
|
3011
|
-
|
|
3012
|
-
|
|
3013
|
-
|
|
3014
|
-
|
|
3015
|
-
|
|
3016
|
-
|
|
3017
|
-
|
|
3018
|
-
|
|
3019
|
-
|
|
3020
|
-
Postel & Reynolds [Page 53]
|
|
3021
|
-
|
|
3022
|
-
|
|
3023
|
-
|
|
3024
|
-
RFC 959 October 1985
|
|
3025
|
-
File Transfer Protocol
|
|
3026
|
-
|
|
3027
|
-
|
|
3028
|
-
6. STATE DIAGRAMS
|
|
3029
|
-
|
|
3030
|
-
Here we present state diagrams for a very simple minded FTP
|
|
3031
|
-
implementation. Only the first digit of the reply codes is used.
|
|
3032
|
-
There is one state diagram for each group of FTP commands or command
|
|
3033
|
-
sequences.
|
|
3034
|
-
|
|
3035
|
-
The command groupings were determined by constructing a model for
|
|
3036
|
-
each command then collecting together the commands with structurally
|
|
3037
|
-
identical models.
|
|
3038
|
-
|
|
3039
|
-
For each command or command sequence there are three possible
|
|
3040
|
-
outcomes: success (S), failure (F), and error (E). In the state
|
|
3041
|
-
diagrams below we use the symbol B for "begin", and the symbol W for
|
|
3042
|
-
"wait for reply".
|
|
3043
|
-
|
|
3044
|
-
We first present the diagram that represents the largest group of FTP
|
|
3045
|
-
commands:
|
|
3046
|
-
|
|
3047
|
-
|
|
3048
|
-
1,3 +---+
|
|
3049
|
-
----------->| E |
|
|
3050
|
-
| +---+
|
|
3051
|
-
|
|
|
3052
|
-
+---+ cmd +---+ 2 +---+
|
|
3053
|
-
| B |---------->| W |---------->| S |
|
|
3054
|
-
+---+ +---+ +---+
|
|
3055
|
-
|
|
|
3056
|
-
| 4,5 +---+
|
|
3057
|
-
----------->| F |
|
|
3058
|
-
+---+
|
|
3059
|
-
|
|
3060
|
-
|
|
3061
|
-
This diagram models the commands:
|
|
3062
|
-
|
|
3063
|
-
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
|
|
3064
|
-
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
|
|
3065
|
-
|
|
3066
|
-
|
|
3067
|
-
|
|
3068
|
-
|
|
3069
|
-
|
|
3070
|
-
|
|
3071
|
-
|
|
3072
|
-
|
|
3073
|
-
|
|
3074
|
-
|
|
3075
|
-
|
|
3076
|
-
|
|
3077
|
-
Postel & Reynolds [Page 54]
|
|
3078
|
-
|
|
3079
|
-
|
|
3080
|
-
|
|
3081
|
-
RFC 959 October 1985
|
|
3082
|
-
File Transfer Protocol
|
|
3083
|
-
|
|
3084
|
-
|
|
3085
|
-
The other large group of commands is represented by a very similar
|
|
3086
|
-
diagram:
|
|
3087
|
-
|
|
3088
|
-
|
|
3089
|
-
3 +---+
|
|
3090
|
-
----------->| E |
|
|
3091
|
-
| +---+
|
|
3092
|
-
|
|
|
3093
|
-
+---+ cmd +---+ 2 +---+
|
|
3094
|
-
| B |---------->| W |---------->| S |
|
|
3095
|
-
+---+ --->+---+ +---+
|
|
3096
|
-
| | |
|
|
3097
|
-
| | | 4,5 +---+
|
|
3098
|
-
| 1 | ----------->| F |
|
|
3099
|
-
----- +---+
|
|
3100
|
-
|
|
3101
|
-
|
|
3102
|
-
This diagram models the commands:
|
|
3103
|
-
|
|
3104
|
-
APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
|
|
3105
|
-
|
|
3106
|
-
Note that this second model could also be used to represent the first
|
|
3107
|
-
group of commands, the only difference being that in the first group
|
|
3108
|
-
the 100 series replies are unexpected and therefore treated as error,
|
|
3109
|
-
while the second group expects (some may require) 100 series replies.
|
|
3110
|
-
Remember that at most, one 100 series reply is allowed per command.
|
|
3111
|
-
|
|
3112
|
-
The remaining diagrams model command sequences, perhaps the simplest
|
|
3113
|
-
of these is the rename sequence:
|
|
3114
|
-
|
|
3115
|
-
|
|
3116
|
-
+---+ RNFR +---+ 1,2 +---+
|
|
3117
|
-
| B |---------->| W |---------->| E |
|
|
3118
|
-
+---+ +---+ -->+---+
|
|
3119
|
-
| | |
|
|
3120
|
-
3 | | 4,5 |
|
|
3121
|
-
-------------- ------ |
|
|
3122
|
-
| | | +---+
|
|
3123
|
-
| ------------->| S |
|
|
3124
|
-
| | 1,3 | | +---+
|
|
3125
|
-
| 2| --------
|
|
3126
|
-
| | | |
|
|
3127
|
-
V | | |
|
|
3128
|
-
+---+ RNTO +---+ 4,5 ----->+---+
|
|
3129
|
-
| |---------->| W |---------->| F |
|
|
3130
|
-
+---+ +---+ +---+
|
|
3131
|
-
|
|
3132
|
-
|
|
3133
|
-
|
|
3134
|
-
Postel & Reynolds [Page 55]
|
|
3135
|
-
|
|
3136
|
-
|
|
3137
|
-
|
|
3138
|
-
RFC 959 October 1985
|
|
3139
|
-
File Transfer Protocol
|
|
3140
|
-
|
|
3141
|
-
|
|
3142
|
-
The next diagram is a simple model of the Restart command:
|
|
3143
|
-
|
|
3144
|
-
|
|
3145
|
-
+---+ REST +---+ 1,2 +---+
|
|
3146
|
-
| B |---------->| W |---------->| E |
|
|
3147
|
-
+---+ +---+ -->+---+
|
|
3148
|
-
| | |
|
|
3149
|
-
3 | | 4,5 |
|
|
3150
|
-
-------------- ------ |
|
|
3151
|
-
| | | +---+
|
|
3152
|
-
| ------------->| S |
|
|
3153
|
-
| | 3 | | +---+
|
|
3154
|
-
| 2| --------
|
|
3155
|
-
| | | |
|
|
3156
|
-
V | | |
|
|
3157
|
-
+---+ cmd +---+ 4,5 ----->+---+
|
|
3158
|
-
| |---------->| W |---------->| F |
|
|
3159
|
-
+---+ -->+---+ +---+
|
|
3160
|
-
| |
|
|
3161
|
-
| 1 |
|
|
3162
|
-
------
|
|
3163
|
-
|
|
3164
|
-
|
|
3165
|
-
Where "cmd" is APPE, STOR, or RETR.
|
|
3166
|
-
|
|
3167
|
-
We note that the above three models are similar. The Restart differs
|
|
3168
|
-
from the Rename two only in the treatment of 100 series replies at
|
|
3169
|
-
the second stage, while the second group expects (some may require)
|
|
3170
|
-
100 series replies. Remember that at most, one 100 series reply is
|
|
3171
|
-
allowed per command.
|
|
3172
|
-
|
|
3173
|
-
|
|
3174
|
-
|
|
3175
|
-
|
|
3176
|
-
|
|
3177
|
-
|
|
3178
|
-
|
|
3179
|
-
|
|
3180
|
-
|
|
3181
|
-
|
|
3182
|
-
|
|
3183
|
-
|
|
3184
|
-
|
|
3185
|
-
|
|
3186
|
-
|
|
3187
|
-
|
|
3188
|
-
|
|
3189
|
-
|
|
3190
|
-
|
|
3191
|
-
Postel & Reynolds [Page 56]
|
|
3192
|
-
|
|
3193
|
-
|
|
3194
|
-
|
|
3195
|
-
RFC 959 October 1985
|
|
3196
|
-
File Transfer Protocol
|
|
3197
|
-
|
|
3198
|
-
|
|
3199
|
-
The most complicated diagram is for the Login sequence:
|
|
3200
|
-
|
|
3201
|
-
|
|
3202
|
-
1
|
|
3203
|
-
+---+ USER +---+------------->+---+
|
|
3204
|
-
| B |---------->| W | 2 ---->| E |
|
|
3205
|
-
+---+ +---+------ | -->+---+
|
|
3206
|
-
| | | | |
|
|
3207
|
-
3 | | 4,5 | | |
|
|
3208
|
-
-------------- ----- | | |
|
|
3209
|
-
| | | | |
|
|
3210
|
-
| | | | |
|
|
3211
|
-
| --------- |
|
|
3212
|
-
| 1| | | |
|
|
3213
|
-
V | | | |
|
|
3214
|
-
+---+ PASS +---+ 2 | ------>+---+
|
|
3215
|
-
| |---------->| W |------------->| S |
|
|
3216
|
-
+---+ +---+ ---------->+---+
|
|
3217
|
-
| | | | |
|
|
3218
|
-
3 | |4,5| | |
|
|
3219
|
-
-------------- -------- |
|
|
3220
|
-
| | | | |
|
|
3221
|
-
| | | | |
|
|
3222
|
-
| -----------
|
|
3223
|
-
| 1,3| | | |
|
|
3224
|
-
V | 2| | |
|
|
3225
|
-
+---+ ACCT +---+-- | ----->+---+
|
|
3226
|
-
| |---------->| W | 4,5 -------->| F |
|
|
3227
|
-
+---+ +---+------------->+---+
|
|
3228
|
-
|
|
3229
|
-
|
|
3230
|
-
|
|
3231
|
-
|
|
3232
|
-
|
|
3233
|
-
|
|
3234
|
-
|
|
3235
|
-
|
|
3236
|
-
|
|
3237
|
-
|
|
3238
|
-
|
|
3239
|
-
|
|
3240
|
-
|
|
3241
|
-
|
|
3242
|
-
|
|
3243
|
-
|
|
3244
|
-
|
|
3245
|
-
|
|
3246
|
-
|
|
3247
|
-
|
|
3248
|
-
Postel & Reynolds [Page 57]
|
|
3249
|
-
|
|
3250
|
-
|
|
3251
|
-
|
|
3252
|
-
RFC 959 October 1985
|
|
3253
|
-
File Transfer Protocol
|
|
3254
|
-
|
|
3255
|
-
|
|
3256
|
-
Finally, we present a generalized diagram that could be used to model
|
|
3257
|
-
the command and reply interchange:
|
|
3258
|
-
|
|
3259
|
-
|
|
3260
|
-
------------------------------------
|
|
3261
|
-
| |
|
|
3262
|
-
Begin | |
|
|
3263
|
-
| V |
|
|
3264
|
-
| +---+ cmd +---+ 2 +---+ |
|
|
3265
|
-
-->| |------->| |---------->| | |
|
|
3266
|
-
| | | W | | S |-----|
|
|
3267
|
-
-->| | -->| |----- | | |
|
|
3268
|
-
| +---+ | +---+ 4,5 | +---+ |
|
|
3269
|
-
| | | | | | |
|
|
3270
|
-
| | | 1| |3 | +---+ |
|
|
3271
|
-
| | | | | | | | |
|
|
3272
|
-
| | ---- | ---->| F |-----
|
|
3273
|
-
| | | | |
|
|
3274
|
-
| | | +---+
|
|
3275
|
-
-------------------
|
|
3276
|
-
|
|
|
3277
|
-
|
|
|
3278
|
-
V
|
|
3279
|
-
End
|
|
3280
|
-
|
|
3281
|
-
|
|
3282
|
-
|
|
3283
|
-
|
|
3284
|
-
|
|
3285
|
-
|
|
3286
|
-
|
|
3287
|
-
|
|
3288
|
-
|
|
3289
|
-
|
|
3290
|
-
|
|
3291
|
-
|
|
3292
|
-
|
|
3293
|
-
|
|
3294
|
-
|
|
3295
|
-
|
|
3296
|
-
|
|
3297
|
-
|
|
3298
|
-
|
|
3299
|
-
|
|
3300
|
-
|
|
3301
|
-
|
|
3302
|
-
|
|
3303
|
-
|
|
3304
|
-
|
|
3305
|
-
Postel & Reynolds [Page 58]
|
|
3306
|
-
|
|
3307
|
-
|
|
3308
|
-
|
|
3309
|
-
RFC 959 October 1985
|
|
3310
|
-
File Transfer Protocol
|
|
3311
|
-
|
|
3312
|
-
|
|
3313
|
-
7. TYPICAL FTP SCENARIO
|
|
3314
|
-
|
|
3315
|
-
User at host U wanting to transfer files to/from host S:
|
|
3316
|
-
|
|
3317
|
-
In general, the user will communicate to the server via a mediating
|
|
3318
|
-
user-FTP process. The following may be a typical scenario. The
|
|
3319
|
-
user-FTP prompts are shown in parentheses, '---->' represents
|
|
3320
|
-
commands from host U to host S, and '<----' represents replies from
|
|
3321
|
-
host S to host U.
|
|
3322
|
-
|
|
3323
|
-
LOCAL COMMANDS BY USER ACTION INVOLVED
|
|
3324
|
-
|
|
3325
|
-
ftp (host) multics<CR> Connect to host S, port L,
|
|
3326
|
-
establishing control connections.
|
|
3327
|
-
<---- 220 Service ready <CRLF>.
|
|
3328
|
-
username Doe <CR> USER Doe<CRLF>---->
|
|
3329
|
-
<---- 331 User name ok,
|
|
3330
|
-
need password<CRLF>.
|
|
3331
|
-
password mumble <CR> PASS mumble<CRLF>---->
|
|
3332
|
-
<---- 230 User logged in<CRLF>.
|
|
3333
|
-
retrieve (local type) ASCII<CR>
|
|
3334
|
-
(local pathname) test 1 <CR> User-FTP opens local file in ASCII.
|
|
3335
|
-
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
|
|
3336
|
-
<---- 150 File status okay;
|
|
3337
|
-
about to open data
|
|
3338
|
-
connection<CRLF>.
|
|
3339
|
-
Server makes data connection
|
|
3340
|
-
to port U.
|
|
3341
|
-
|
|
3342
|
-
<---- 226 Closing data connection,
|
|
3343
|
-
file transfer successful<CRLF>.
|
|
3344
|
-
type Image<CR> TYPE I<CRLF> ---->
|
|
3345
|
-
<---- 200 Command OK<CRLF>
|
|
3346
|
-
store (local type) image<CR>
|
|
3347
|
-
(local pathname) file dump<CR> User-FTP opens local file in Image.
|
|
3348
|
-
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
|
|
3349
|
-
<---- 550 Access denied<CRLF>
|
|
3350
|
-
terminate QUIT <CRLF> ---->
|
|
3351
|
-
Server closes all
|
|
3352
|
-
connections.
|
|
3353
|
-
|
|
3354
|
-
8. CONNECTION ESTABLISHMENT
|
|
3355
|
-
|
|
3356
|
-
The FTP control connection is established via TCP between the user
|
|
3357
|
-
process port U and the server process port L. This protocol is
|
|
3358
|
-
assigned the service port 21 (25 octal), that is L=21.
|
|
3359
|
-
|
|
3360
|
-
|
|
3361
|
-
|
|
3362
|
-
Postel & Reynolds [Page 59]
|
|
3363
|
-
|
|
3364
|
-
|
|
3365
|
-
|
|
3366
|
-
RFC 959 October 1985
|
|
3367
|
-
File Transfer Protocol
|
|
3368
|
-
|
|
3369
|
-
|
|
3370
|
-
APPENDIX I - PAGE STRUCTURE
|
|
3371
|
-
|
|
3372
|
-
The need for FTP to support page structure derives principally from
|
|
3373
|
-
the need to support efficient transmission of files between TOPS-20
|
|
3374
|
-
systems, particularly the files used by NLS.
|
|
3375
|
-
|
|
3376
|
-
The file system of TOPS-20 is based on the concept of pages. The
|
|
3377
|
-
operating system is most efficient at manipulating files as pages.
|
|
3378
|
-
The operating system provides an interface to the file system so that
|
|
3379
|
-
many applications view files as sequential streams of characters.
|
|
3380
|
-
However, a few applications use the underlying page structures
|
|
3381
|
-
directly, and some of these create holey files.
|
|
3382
|
-
|
|
3383
|
-
A TOPS-20 disk file consists of four things: a pathname, a page
|
|
3384
|
-
table, a (possibly empty) set of pages, and a set of attributes.
|
|
3385
|
-
|
|
3386
|
-
The pathname is specified in the RETR or STOR command. It includes
|
|
3387
|
-
the directory name, file name, file name extension, and generation
|
|
3388
|
-
number.
|
|
3389
|
-
|
|
3390
|
-
The page table contains up to 2**18 entries. Each entry may be
|
|
3391
|
-
EMPTY, or may point to a page. If it is not empty, there are also
|
|
3392
|
-
some page-specific access bits; not all pages of a file need have the
|
|
3393
|
-
same access protection.
|
|
3394
|
-
|
|
3395
|
-
A page is a contiguous set of 512 words of 36 bits each.
|
|
3396
|
-
|
|
3397
|
-
The attributes of the file, in the File Descriptor Block (FDB),
|
|
3398
|
-
contain such things as creation time, write time, read time, writer's
|
|
3399
|
-
byte-size, end-of-file pointer, count of reads and writes, backup
|
|
3400
|
-
system tape numbers, etc.
|
|
3401
|
-
|
|
3402
|
-
Note that there is NO requirement that entries in the page table be
|
|
3403
|
-
contiguous. There may be empty page table slots between occupied
|
|
3404
|
-
ones. Also, the end of file pointer is simply a number. There is no
|
|
3405
|
-
requirement that it in fact point at the "last" datum in the file.
|
|
3406
|
-
Ordinary sequential I/O calls in TOPS-20 will cause the end of file
|
|
3407
|
-
pointer to be left after the last datum written, but other operations
|
|
3408
|
-
may cause it not to be so, if a particular programming system so
|
|
3409
|
-
requires.
|
|
3410
|
-
|
|
3411
|
-
In fact, in both of these special cases, "holey" files and
|
|
3412
|
-
end-of-file pointers NOT at the end of the file, occur with NLS data
|
|
3413
|
-
files.
|
|
3414
|
-
|
|
3415
|
-
|
|
3416
|
-
|
|
3417
|
-
|
|
3418
|
-
|
|
3419
|
-
Postel & Reynolds [Page 60]
|
|
3420
|
-
|
|
3421
|
-
|
|
3422
|
-
|
|
3423
|
-
RFC 959 October 1985
|
|
3424
|
-
File Transfer Protocol
|
|
3425
|
-
|
|
3426
|
-
|
|
3427
|
-
The TOPS-20 paged files can be sent with the FTP transfer parameters:
|
|
3428
|
-
TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
|
|
3429
|
-
|
|
3430
|
-
Each page of information has a header. Each header field, which is a
|
|
3431
|
-
logical byte, is a TOPS-20 word, since the TYPE is L 36.
|
|
3432
|
-
|
|
3433
|
-
The header fields are:
|
|
3434
|
-
|
|
3435
|
-
Word 0: Header Length.
|
|
3436
|
-
|
|
3437
|
-
The header length is 5.
|
|
3438
|
-
|
|
3439
|
-
Word 1: Page Index.
|
|
3440
|
-
|
|
3441
|
-
If the data is a disk file page, this is the number of that
|
|
3442
|
-
page in the file's page map. Empty pages (holes) in the file
|
|
3443
|
-
are simply not sent. Note that a hole is NOT the same as a
|
|
3444
|
-
page of zeros.
|
|
3445
|
-
|
|
3446
|
-
Word 2: Data Length.
|
|
3447
|
-
|
|
3448
|
-
The number of data words in this page, following the header.
|
|
3449
|
-
Thus, the total length of the transmission unit is the Header
|
|
3450
|
-
Length plus the Data Length.
|
|
3451
|
-
|
|
3452
|
-
Word 3: Page Type.
|
|
3453
|
-
|
|
3454
|
-
A code for what type of chunk this is. A data page is type 3,
|
|
3455
|
-
the FDB page is type 2.
|
|
3456
|
-
|
|
3457
|
-
Word 4: Page Access Control.
|
|
3458
|
-
|
|
3459
|
-
The access bits associated with the page in the file's page
|
|
3460
|
-
map. (This full word quantity is put into AC2 of an SPACS by
|
|
3461
|
-
the program reading from net to disk.)
|
|
3462
|
-
|
|
3463
|
-
After the header are Data Length data words. Data Length is
|
|
3464
|
-
currently either 512 for a data page or 31 for an FDB. Trailing
|
|
3465
|
-
zeros in a disk file page may be discarded, making Data Length less
|
|
3466
|
-
than 512 in that case.
|
|
3467
|
-
|
|
3468
|
-
|
|
3469
|
-
|
|
3470
|
-
|
|
3471
|
-
|
|
3472
|
-
|
|
3473
|
-
|
|
3474
|
-
|
|
3475
|
-
|
|
3476
|
-
Postel & Reynolds [Page 61]
|
|
3477
|
-
|
|
3478
|
-
|
|
3479
|
-
|
|
3480
|
-
RFC 959 October 1985
|
|
3481
|
-
File Transfer Protocol
|
|
3482
|
-
|
|
3483
|
-
|
|
3484
|
-
APPENDIX II - DIRECTORY COMMANDS
|
|
3485
|
-
|
|
3486
|
-
Since UNIX has a tree-like directory structure in which directories
|
|
3487
|
-
are as easy to manipulate as ordinary files, it is useful to expand
|
|
3488
|
-
the FTP servers on these machines to include commands which deal with
|
|
3489
|
-
the creation of directories. Since there are other hosts on the
|
|
3490
|
-
ARPA-Internet which have tree-like directories (including TOPS-20 and
|
|
3491
|
-
Multics), these commands are as general as possible.
|
|
3492
|
-
|
|
3493
|
-
Four directory commands have been added to FTP:
|
|
3494
|
-
|
|
3495
|
-
MKD pathname
|
|
3496
|
-
|
|
3497
|
-
Make a directory with the name "pathname".
|
|
3498
|
-
|
|
3499
|
-
RMD pathname
|
|
3500
|
-
|
|
3501
|
-
Remove the directory with the name "pathname".
|
|
3502
|
-
|
|
3503
|
-
PWD
|
|
3504
|
-
|
|
3505
|
-
Print the current working directory name.
|
|
3506
|
-
|
|
3507
|
-
CDUP
|
|
3508
|
-
|
|
3509
|
-
Change to the parent of the current working directory.
|
|
3510
|
-
|
|
3511
|
-
The "pathname" argument should be created (removed) as a
|
|
3512
|
-
subdirectory of the current working directory, unless the "pathname"
|
|
3513
|
-
string contains sufficient information to specify otherwise to the
|
|
3514
|
-
server, e.g., "pathname" is an absolute pathname (in UNIX and
|
|
3515
|
-
Multics), or pathname is something like "<abso.lute.path>" to
|
|
3516
|
-
TOPS-20.
|
|
3517
|
-
|
|
3518
|
-
REPLY CODES
|
|
3519
|
-
|
|
3520
|
-
The CDUP command is a special case of CWD, and is included to
|
|
3521
|
-
simplify the implementation of programs for transferring directory
|
|
3522
|
-
trees between operating systems having different syntaxes for
|
|
3523
|
-
naming the parent directory. The reply codes for CDUP be
|
|
3524
|
-
identical to the reply codes of CWD.
|
|
3525
|
-
|
|
3526
|
-
The reply codes for RMD be identical to the reply codes for its
|
|
3527
|
-
file analogue, DELE.
|
|
3528
|
-
|
|
3529
|
-
The reply codes for MKD, however, are a bit more complicated. A
|
|
3530
|
-
freshly created directory will probably be the object of a future
|
|
3531
|
-
|
|
3532
|
-
|
|
3533
|
-
Postel & Reynolds [Page 62]
|
|
3534
|
-
|
|
3535
|
-
|
|
3536
|
-
|
|
3537
|
-
RFC 959 October 1985
|
|
3538
|
-
File Transfer Protocol
|
|
3539
|
-
|
|
3540
|
-
|
|
3541
|
-
CWD command. Unfortunately, the argument to MKD may not always be
|
|
3542
|
-
a suitable argument for CWD. This is the case, for example, when
|
|
3543
|
-
a TOPS-20 subdirectory is created by giving just the subdirectory
|
|
3544
|
-
name. That is, with a TOPS-20 server FTP, the command sequence
|
|
3545
|
-
|
|
3546
|
-
MKD MYDIR
|
|
3547
|
-
CWD MYDIR
|
|
3548
|
-
|
|
3549
|
-
will fail. The new directory may only be referred to by its
|
|
3550
|
-
"absolute" name; e.g., if the MKD command above were issued while
|
|
3551
|
-
connected to the directory <DFRANKLIN>, the new subdirectory
|
|
3552
|
-
could only be referred to by the name <DFRANKLIN.MYDIR>.
|
|
3553
|
-
|
|
3554
|
-
Even on UNIX and Multics, however, the argument given to MKD may
|
|
3555
|
-
not be suitable. If it is a "relative" pathname (i.e., a pathname
|
|
3556
|
-
which is interpreted relative to the current directory), the user
|
|
3557
|
-
would need to be in the same current directory in order to reach
|
|
3558
|
-
the subdirectory. Depending on the application, this may be
|
|
3559
|
-
inconvenient. It is not very robust in any case.
|
|
3560
|
-
|
|
3561
|
-
To solve these problems, upon successful completion of an MKD
|
|
3562
|
-
command, the server should return a line of the form:
|
|
3563
|
-
|
|
3564
|
-
257<space>"<directory-name>"<space><commentary>
|
|
3565
|
-
|
|
3566
|
-
That is, the server will tell the user what string to use when
|
|
3567
|
-
referring to the created directory. The directory name can
|
|
3568
|
-
contain any character; embedded double-quotes should be escaped by
|
|
3569
|
-
double-quotes (the "quote-doubling" convention).
|
|
3570
|
-
|
|
3571
|
-
For example, a user connects to the directory /usr/dm, and creates
|
|
3572
|
-
a subdirectory, named pathname:
|
|
3573
|
-
|
|
3574
|
-
CWD /usr/dm
|
|
3575
|
-
200 directory changed to /usr/dm
|
|
3576
|
-
MKD pathname
|
|
3577
|
-
257 "/usr/dm/pathname" directory created
|
|
3578
|
-
|
|
3579
|
-
An example with an embedded double quote:
|
|
3580
|
-
|
|
3581
|
-
MKD foo"bar
|
|
3582
|
-
257 "/usr/dm/foo""bar" directory created
|
|
3583
|
-
CWD /usr/dm/foo"bar
|
|
3584
|
-
200 directory changed to /usr/dm/foo"bar
|
|
3585
|
-
|
|
3586
|
-
|
|
3587
|
-
|
|
3588
|
-
|
|
3589
|
-
|
|
3590
|
-
Postel & Reynolds [Page 63]
|
|
3591
|
-
|
|
3592
|
-
|
|
3593
|
-
|
|
3594
|
-
RFC 959 October 1985
|
|
3595
|
-
File Transfer Protocol
|
|
3596
|
-
|
|
3597
|
-
|
|
3598
|
-
The prior existence of a subdirectory with the same name is an
|
|
3599
|
-
error, and the server must return an "access denied" error reply
|
|
3600
|
-
in that case.
|
|
3601
|
-
|
|
3602
|
-
CWD /usr/dm
|
|
3603
|
-
200 directory changed to /usr/dm
|
|
3604
|
-
MKD pathname
|
|
3605
|
-
521-"/usr/dm/pathname" directory already exists;
|
|
3606
|
-
521 taking no action.
|
|
3607
|
-
|
|
3608
|
-
The failure replies for MKD are analogous to its file creating
|
|
3609
|
-
cousin, STOR. Also, an "access denied" return is given if a file
|
|
3610
|
-
name with the same name as the subdirectory will conflict with the
|
|
3611
|
-
creation of the subdirectory (this is a problem on UNIX, but
|
|
3612
|
-
shouldn't be one on TOPS-20).
|
|
3613
|
-
|
|
3614
|
-
Essentially because the PWD command returns the same type of
|
|
3615
|
-
information as the successful MKD command, the successful PWD
|
|
3616
|
-
command uses the 257 reply code as well.
|
|
3617
|
-
|
|
3618
|
-
SUBTLETIES
|
|
3619
|
-
|
|
3620
|
-
Because these commands will be most useful in transferring
|
|
3621
|
-
subtrees from one machine to another, carefully observe that the
|
|
3622
|
-
argument to MKD is to be interpreted as a sub-directory of the
|
|
3623
|
-
current working directory, unless it contains enough information
|
|
3624
|
-
for the destination host to tell otherwise. A hypothetical
|
|
3625
|
-
example of its use in the TOPS-20 world:
|
|
3626
|
-
|
|
3627
|
-
CWD <some.where>
|
|
3628
|
-
200 Working directory changed
|
|
3629
|
-
MKD overrainbow
|
|
3630
|
-
257 "<some.where.overrainbow>" directory created
|
|
3631
|
-
CWD overrainbow
|
|
3632
|
-
431 No such directory
|
|
3633
|
-
CWD <some.where.overrainbow>
|
|
3634
|
-
200 Working directory changed
|
|
3635
|
-
|
|
3636
|
-
CWD <some.where>
|
|
3637
|
-
200 Working directory changed to <some.where>
|
|
3638
|
-
MKD <unambiguous>
|
|
3639
|
-
257 "<unambiguous>" directory created
|
|
3640
|
-
CWD <unambiguous>
|
|
3641
|
-
|
|
3642
|
-
Note that the first example results in a subdirectory of the
|
|
3643
|
-
connected directory. In contrast, the argument in the second
|
|
3644
|
-
example contains enough information for TOPS-20 to tell that the
|
|
3645
|
-
|
|
3646
|
-
|
|
3647
|
-
Postel & Reynolds [Page 64]
|
|
3648
|
-
|
|
3649
|
-
|
|
3650
|
-
|
|
3651
|
-
RFC 959 October 1985
|
|
3652
|
-
File Transfer Protocol
|
|
3653
|
-
|
|
3654
|
-
|
|
3655
|
-
<unambiguous> directory is a top-level directory. Note also that
|
|
3656
|
-
in the first example the user "violated" the protocol by
|
|
3657
|
-
attempting to access the freshly created directory with a name
|
|
3658
|
-
other than the one returned by TOPS-20. Problems could have
|
|
3659
|
-
resulted in this case had there been an <overrainbow> directory;
|
|
3660
|
-
this is an ambiguity inherent in some TOPS-20 implementations.
|
|
3661
|
-
Similar considerations apply to the RMD command. The point is
|
|
3662
|
-
this: except where to do so would violate a host's conventions for
|
|
3663
|
-
denoting relative versus absolute pathnames, the host should treat
|
|
3664
|
-
the operands of the MKD and RMD commands as subdirectories. The
|
|
3665
|
-
257 reply to the MKD command must always contain the absolute
|
|
3666
|
-
pathname of the created directory.
|
|
3667
|
-
|
|
3668
|
-
|
|
3669
|
-
|
|
3670
|
-
|
|
3671
|
-
|
|
3672
|
-
|
|
3673
|
-
|
|
3674
|
-
|
|
3675
|
-
|
|
3676
|
-
|
|
3677
|
-
|
|
3678
|
-
|
|
3679
|
-
|
|
3680
|
-
|
|
3681
|
-
|
|
3682
|
-
|
|
3683
|
-
|
|
3684
|
-
|
|
3685
|
-
|
|
3686
|
-
|
|
3687
|
-
|
|
3688
|
-
|
|
3689
|
-
|
|
3690
|
-
|
|
3691
|
-
|
|
3692
|
-
|
|
3693
|
-
|
|
3694
|
-
|
|
3695
|
-
|
|
3696
|
-
|
|
3697
|
-
|
|
3698
|
-
|
|
3699
|
-
|
|
3700
|
-
|
|
3701
|
-
|
|
3702
|
-
|
|
3703
|
-
|
|
3704
|
-
Postel & Reynolds [Page 65]
|
|
3705
|
-
|
|
3706
|
-
|
|
3707
|
-
|
|
3708
|
-
RFC 959 October 1985
|
|
3709
|
-
File Transfer Protocol
|
|
3710
|
-
|
|
3711
|
-
|
|
3712
|
-
APPENDIX III - RFCs on FTP
|
|
3713
|
-
|
|
3714
|
-
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
|
|
3715
|
-
MIT-Project MAC, 16 April 1971.
|
|
3716
|
-
|
|
3717
|
-
Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
|
|
3718
|
-
Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
|
|
3719
|
-
|
|
3720
|
-
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
|
|
3721
|
-
(NIC 6794), MIT-Project MAC, 23 June 1971.
|
|
3722
|
-
|
|
3723
|
-
Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
|
|
3724
|
-
UCLA/CCN, 29 September 1971.
|
|
3725
|
-
|
|
3726
|
-
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
|
|
3727
|
-
(NIC 7813), MIT-Project MAC, 17 November 1971.
|
|
3728
|
-
|
|
3729
|
-
McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
|
|
3730
|
-
RFC 281 (NIC 8163), BBN, 8 December 1971.
|
|
3731
|
-
|
|
3732
|
-
Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
|
|
3733
|
-
Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
|
|
3734
|
-
25 January 1972.
|
|
3735
|
-
|
|
3736
|
-
Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
|
|
3737
|
-
MIT-Project MAC, 8 July 1972.
|
|
3738
|
-
|
|
3739
|
-
Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
|
|
3740
|
-
RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
|
|
3741
|
-
|
|
3742
|
-
Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
|
|
3743
|
-
27 November 1972.
|
|
3744
|
-
|
|
3745
|
-
Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
|
|
3746
|
-
Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
|
|
3747
|
-
|
|
3748
|
-
Braden, Bob, "Comments on File Transfer Protocol", RFC 430
|
|
3749
|
-
(NIC 13299), UCLA/CCN, 7 February 1973.
|
|
3750
|
-
|
|
3751
|
-
Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
|
|
3752
|
-
RFC 438 (NIC 13770), BBN, 15 January 1973.
|
|
3753
|
-
|
|
3754
|
-
Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
|
|
3755
|
-
27 February 1973.
|
|
3756
|
-
|
|
3757
|
-
McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
|
|
3758
|
-
16 February 1973.
|
|
3759
|
-
|
|
3760
|
-
|
|
3761
|
-
Postel & Reynolds [Page 66]
|
|
3762
|
-
|
|
3763
|
-
|
|
3764
|
-
|
|
3765
|
-
RFC 959 October 1985
|
|
3766
|
-
File Transfer Protocol
|
|
3767
|
-
|
|
3768
|
-
|
|
3769
|
-
Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
|
|
3770
|
-
(NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
|
|
3771
|
-
|
|
3772
|
-
Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
|
|
3773
|
-
12 July 1973.
|
|
3774
|
-
|
|
3775
|
-
Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
|
|
3776
|
-
Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
|
|
3777
|
-
|
|
3778
|
-
Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
|
|
3779
|
-
File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
|
|
3780
|
-
|
|
3781
|
-
Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
|
|
3782
|
-
"Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
|
|
3783
|
-
Ames Research Center, SRI-ARC, 28 February 1974.
|
|
3784
|
-
|
|
3785
|
-
Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
|
|
3786
|
-
(NIC 14573), MIT-DMCG, 21 February 1973.
|
|
3787
|
-
|
|
3788
|
-
Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
|
|
3789
|
-
8 March 1973.
|
|
3790
|
-
|
|
3791
|
-
Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
|
|
3792
|
-
MIT-DMCG, 6 March 1973.
|
|
3793
|
-
|
|
3794
|
-
Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
|
|
3795
|
-
RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
|
|
3796
|
-
|
|
3797
|
-
White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
|
|
3798
|
-
SRI-ARC, 8 March 1973.
|
|
3799
|
-
|
|
3800
|
-
White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
|
|
3801
|
-
SRI-ARC, 8 March 1973.
|
|
3802
|
-
|
|
3803
|
-
Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
|
|
3804
|
-
(NIC 16157), MIT-Multics, 26 June 1973.
|
|
3805
|
-
|
|
3806
|
-
Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
|
|
3807
|
-
RFC 520 (NIC 16819), Illinois, 25 June 1973.
|
|
3808
|
-
|
|
3809
|
-
Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
|
|
3810
|
-
(NIC 17451), UCSD-CC, 22 June 1973.
|
|
3811
|
-
|
|
3812
|
-
Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
|
|
3813
|
-
15 November 1973.
|
|
3814
|
-
|
|
3815
|
-
|
|
3816
|
-
|
|
3817
|
-
|
|
3818
|
-
Postel & Reynolds [Page 67]
|
|
3819
|
-
|
|
3820
|
-
|
|
3821
|
-
|
|
3822
|
-
RFC 959 October 1985
|
|
3823
|
-
File Transfer Protocol
|
|
3824
|
-
|
|
3825
|
-
|
|
3826
|
-
McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
|
|
3827
|
-
Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
|
|
3828
|
-
29 November 1973.
|
|
3829
|
-
|
|
3830
|
-
Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
|
|
3831
|
-
Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
|
|
3832
|
-
|
|
3833
|
-
Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
|
|
3834
|
-
UCLA/NMC, 5 June 1974.
|
|
3835
|
-
|
|
3836
|
-
Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
|
|
3837
|
-
SU-AI, 10 May 1975.
|
|
3838
|
-
|
|
3839
|
-
Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
|
|
3840
|
-
28 May 1975.
|
|
3841
|
-
|
|
3842
|
-
Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
|
|
3843
|
-
|
|
3844
|
-
Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
|
|
3845
|
-
31 October 1977.
|
|
3846
|
-
|
|
3847
|
-
Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
|
|
3848
|
-
SRI-KL, 30 December 1977.
|
|
3849
|
-
|
|
3850
|
-
Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
|
|
3851
|
-
10 December 1978.
|
|
3852
|
-
|
|
3853
|
-
Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
|
|
3854
|
-
June 1980.
|
|
3855
|
-
|
|
3856
|
-
Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
|
|
3857
|
-
Commands", RFC 776, BBN, December 1980.
|
|
3858
|
-
|
|
3859
|
-
Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
|
|
3860
|
-
July 1985.
|
|
3861
|
-
|
|
3862
|
-
|
|
3863
|
-
|
|
3864
|
-
|
|
3865
|
-
|
|
3866
|
-
|
|
3867
|
-
|
|
3868
|
-
|
|
3869
|
-
|
|
3870
|
-
|
|
3871
|
-
|
|
3872
|
-
|
|
3873
|
-
|
|
3874
|
-
|
|
3875
|
-
Postel & Reynolds [Page 68]
|
|
3876
|
-
|
|
3877
|
-
|
|
3878
|
-
|
|
3879
|
-
RFC 959 October 1985
|
|
3880
|
-
File Transfer Protocol
|
|
3881
|
-
|
|
3882
|
-
|
|
3883
|
-
REFERENCES
|
|
3884
|
-
|
|
3885
|
-
[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
|
|
3886
|
-
Network Information Center, SRI International, March 1982.
|
|
3887
|
-
|
|
3888
|
-
[2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
|
|
3889
|
-
Program Protocol Specification", RFC 793, DARPA, September 1981.
|
|
3890
|
-
|
|
3891
|
-
[3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
|
|
3892
|
-
Specification", RFC 854, ISI, May 1983.
|
|
3893
|
-
|
|
3894
|
-
[4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
|
|
3895
|
-
ISI, April 1985.
|
|
3896
|
-
|
|
3897
|
-
|
|
3898
|
-
|
|
3899
|
-
|
|
3900
|
-
|
|
3901
|
-
|
|
3902
|
-
|
|
3903
|
-
|
|
3904
|
-
|
|
3905
|
-
|
|
3906
|
-
|
|
3907
|
-
|
|
3908
|
-
|
|
3909
|
-
|
|
3910
|
-
|
|
3911
|
-
|
|
3912
|
-
|
|
3913
|
-
|
|
3914
|
-
|
|
3915
|
-
|
|
3916
|
-
|
|
3917
|
-
|
|
3918
|
-
|
|
3919
|
-
|
|
3920
|
-
|
|
3921
|
-
|
|
3922
|
-
|
|
3923
|
-
|
|
3924
|
-
|
|
3925
|
-
|
|
3926
|
-
|
|
3927
|
-
|
|
3928
|
-
|
|
3929
|
-
|
|
3930
|
-
|
|
3931
|
-
|
|
3932
|
-
Postel & Reynolds [Page 69]
|
|
3933
|
-
|