ftpd 2.0.1 → 2.0.2

data/features/ftp_server/eprt.feature

@@ -1,56 +0,0 @@
-Feature: EPRT
-
-  As a programmer
-  I want good error messages
-  So that I can correct problems
-
-  Background:
-    Given the stack supports ipv6
-    Given the test server is bound to "::"
-    Given the test server is started
-
-  Scenario: Port 1024
-    Given a successful login
-    Then the client successfully sends "EPRT |1|1.2.3.4|1024|"
-
-  Scenario: Port 1023; low ports disallowed
-    Given the test server disallows low data ports
-    And a successful login
-    When the client sends "EPRT |1|2.3.4.3|255|"
-    Then the server returns an unimplemented parameter error
-
-  Scenario: Port out of range
-    Given a successful login
-    When the client sends "EPRT |1|2.3.4.5|65536|"
-    Then the server returns an unimplemented parameter error
-
-  Scenario: Port 1023; low ports allowed
-    Given the test server allows low data ports
-    And a successful login
-    Then the client successfully sends "EPRT |1|2.3.4.3|255|"
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client sends "EPRT |1|2.3.4.5|6|"
-    Then the server returns a not logged in error
-
-  Scenario: Too few parts
-    Given a successful login
-    When the client sends "EPRT |1|2.3.4|"
-    Then the server returns a syntax error
-
-  Scenario: Too many parts
-    Given a successful login
-    When the client sends "EPRT |1|2.3.4|5|6|"
-    Then the server returns a syntax error
-
-  Scenario: Unknown network protocol
-    Given a successful login
-    When the client sends "EPRT |3|2.3.4.5|6|"
-    Then the server returns a network protocol not supported error
-
-  Scenario: After "EPSV ALL"
-    Given a successful login
-    Given the client successfully sends "EPSV ALL"
-    When the client sends "EPRT |1|2.3.4.5|6|"
-    Then the server sends a not allowed after epsv all error

data/features/ftp_server/epsv.feature

@@ -1,37 +0,0 @@
-Feature: EPSV
-
-  As a programmer
-  I want good error messages
-  So that I can correct problems
-
-  Background:
-    Given the stack supports ipv6
-    Given the test server is bound to "::"
-    And the test server is started
-
-  Scenario: No argument
-    Given a successful login
-    Then the client successfully sends "EPSV"
-
-  Scenario: Explicit IPV4
-    Given a successful login
-    Then the client successfully sends "EPSV 1"
-
-  Scenario: Explicit IPV6
-    Given a successful login
-    Then the client successfully sends "EPSV 2"
-
-  Scenario: After "EPSV ALL"
-    Given a successful login
-    Given the client successfully sends "EPSV ALL"
-    Then the client successfully sends "EPSV"
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client sends "EPSV"
-    Then the server returns a not logged in error
-
-  Scenario: Unknown network protocol
-    Given a successful login
-    When the client sends "EPSV 99"
-    Then the server returns a network protocol not supported error

data/features/ftp_server/features.feature

@@ -1,38 +0,0 @@
-Feature: Features
-
-  As a client
-  I want to know what FTP extension the server supports
-  So that I can use them without trial-and-error
-
-  Background:
-
-  Scenario: TLS Disabled
-    Given the test server is started
-    And the client connects
-    When the client successfully requests features
-    Then the response should not include TLS features
-
-  Scenario: TLS Enabled
-    Given the test server has TLS mode "explicit"
-    And the test server is started
-    And the client connects
-    When the client successfully requests features
-    Then the response should include TLS features
-
-  Scenario: Argument given
-    Given the test server is started
-    And the client connects
-    When the client sends "FEAT FOO"
-    Then the server returns a syntax error
-
-  Scenario: IPV6 Extensions
-    Given the test server is started
-    When the client successfully requests features
-    Then the response should include feature "EPRT"
-    And the response should include feature "EPSV"
-
-  Scenario: RFC 3659 Extensions
-    Given the test server is started
-    When the client successfully requests features
-    Then the response should include feature "SIZE"
-    Then the response should include feature "MDTM"

data/features/ftp_server/file_structure.feature

@@ -1,43 +0,0 @@
-Feature: File Structure
-
-  As a server
-  I want to accept the obsolute file structure (STRU) command
-  For compatability
-
-  Background:
-    Given the test server is started
-
-  Scenario: File
-  Given a successful login
-  And the server has file "ascii_unix"
-  When the client successfully sets file structure "F"
-  And the client successfully gets text "ascii_unix"
-  Then the remote file "ascii_unix" should match the local file
-
-  Scenario: Record
-    Given a successful login
-    And the server has file "ascii_unix"
-    When the client sets file structure "R"
-    Then the server returns a file structure not implemented error
-
-  Scenario: Page
-    Given a successful login
-    And the server has file "ascii_unix"
-    When the client sets file structure "P"
-    Then the server returns a file structure not implemented error
-
-  Scenario: Invalid
-    Given a successful login
-    And the server has file "ascii_unix"
-    When the client sets file structure "*"
-    Then the server returns an invalid file structure error
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client sets file structure "F"
-    Then the server returns a not logged in error
-
-  Scenario: Missing parameter
-    Given a successful login
-    When the client sets file structure with no parameter
-    Then the server returns a syntax error

data/features/ftp_server/get.feature

@@ -1,80 +0,0 @@
-Feature: Get
-
-  As a client
-  I want to securely get a file
-  So that I have it on my computer
-  But nobody else can
-
-  Background:
-    Given the test server is started
-
-  Scenario: ASCII file with *nix line endings
-    Given a successful login
-    And the server has file "ascii_unix"
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file
-    And the local file "ascii_unix" should have unix line endings
-
-  Scenario: ASCII file with windows line endings
-    Given a successful login
-    And the server has file "ascii_windows"
-    When the client successfully gets text "ascii_windows"
-    Then the local file "ascii_windows" should match the remote file
-    And the local file "ascii_windows" should have unix line endings
-
-  Scenario: Binary file
-    Given a successful login
-    And the server has file "binary"
-    When the client successfully gets binary "binary"
-    Then the local file "binary" should exactly match the remote file
-
-  Scenario: Passive
-    Given a successful login
-    And the server has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file
-
-  Scenario: File in subdirectory
-    Given a successful login
-    And the server has file "foo/ascii_unix"
-    Then the client successfully gets text "foo/ascii_unix"
-
-  Scenario: Non-root working directory
-    Given a successful login
-    And the server has file "foo/ascii_unix"
-    And the client successfully cd's to "foo"
-    When the client successfully gets text "ascii_unix"
-    Then the remote file "foo/ascii_unix" should match the local file
-
-  Scenario: Access denied
-    Given a successful login
-    When the client gets text "forbidden"
-    Then the server returns an access denied error
-
-  Scenario: Missing file
-    Given a successful login
-    When the client gets text "foo"
-    Then the server returns a not found error
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client gets text "foo"
-    Then the server returns a not logged in error
-
-  Scenario: Missing path
-    Given a successful login
-    When the client gets with no path
-    Then the server returns a syntax error
-
-  Scenario: File system error
-    Given a successful login
-    When the client gets text "unable"
-    Then the server returns an action not taken error
-
-  Scenario: Read not enabled
-    Given the test server lacks read
-    And a successful login
-    And the server has file "foo"
-    When the client gets text "foo"
-    Then the server returns an unimplemented command error

data/features/ftp_server/get_ipv6.feature

@@ -1,46 +0,0 @@
-Feature: Get IPV6
-
-  As a client
-  I want to get a file
-  So that I have it on my computer
-
-  Background:
-    Given the stack supports ipv6
-
-  Scenario: Active
-    Given the test server is bound to "::1"
-    And the test server is started
-    And a successful login
-    And the server has file "ascii_unix"
-    And the client is in active mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file
-
-  Scenario: Passive
-    Given the test server is bound to "::1"
-    And the test server is started
-    And a successful login
-    And the server has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file
-
-  Scenario: Active, TLS
-    Given the test server is bound to "::1"
-    And the test server has TLS mode "explicit"
-    And the test server is started
-    And a successful login
-    And the server has file "ascii_unix"
-    And the client is in active mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file
-
-  Scenario: Passive, TLS
-    Given the test server is bound to "::1"
-    And the test server has TLS mode "explicit"
-    And the test server is started
-    And a successful login
-    And the server has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file

data/features/ftp_server/get_tls.feature

@@ -1,23 +0,0 @@
-Feature: Get TLS
-
-  As a client
-  I want to get a file
-  So that I have it on my computer
-
-  Background:
-    Given the test server has TLS mode "explicit"
-    And the test server is started
-
-  Scenario: Active
-    Given a successful login with explicit TLS
-    And the server has file "ascii_unix"
-    And the client is in active mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file
-
-  Scenario: Passive
-    Given a successful login with explicit TLS
-    And the server has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully gets text "ascii_unix"
-    Then the local file "ascii_unix" should match the remote file

data/features/ftp_server/help.feature

@@ -1,21 +0,0 @@
-Feature: Help
-
-  As a client
-  I want to ask for help
-  So that I can know which commands are supported
-
-  Background:
-    Given the test server is started
-    And a successful connection
-
-  Scenario: No argument
-    When the client successfully asks for help
-    Then the server should return a list of commands
-
-  Scenario: Known command
-    When the client successfully asks for help for "NOOP"
-    Then the server should return help for "NOOP"
-
-  Scenario: Unknown command
-    When the client successfully asks for help for "FOO"
-    Then the server should return no help for "FOO"

data/features/ftp_server/implicit_tls.feature

@@ -1,23 +0,0 @@
-Feature: Implicit TLS
-
-  As a server
-  I want to use implicit TLS
-  Because I must serve out-of-date clients
-
-  Background:
-    Given the test server has TLS mode "implicit"
-    And the test server is started
-
-  Scenario: Active
-    Given a successful login with implicit TLS
-    And the client has file "ascii_unix"
-    And the client is in active mode
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "ascii_unix" should match the local file
-
-  Scenario: Passive
-    Given a successful login with implicit TLS
-    And the client has file "ascii_unix"
-    And the client is in passive mode
-    When the client successfully puts text "ascii_unix"
-    Then the remote file "ascii_unix" should match the local file

data/features/ftp_server/invertability.feature

@@ -1,15 +0,0 @@
-Feature: Get
-
-  As a client
-  I want a file to be the same when I get it as it was when I put it
-  So that I can use the FTP server for storage
-
-  Background:
-    Given the test server is started
-
-  Scenario: Binary file
-    Given a successful login
-    And the client has file "binary"
-    When the client successfully puts binary "binary"
-    And the client successfully gets binary "binary"
-    Then the local file "binary" should match its template

data/features/ftp_server/list.feature

@@ -1,94 +0,0 @@
-Feature: List
-
-  As a client
-  I want to list files
-  So that I can see what file to transfer
-
-  Background:
-    Given the test server is started
-
-  Scenario: Implicit
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    When the client successfully lists the directory
-    Then the file list should be in long form
-    And the file list should contain "foo"
-    And the file list should contain "bar"
-
-  Scenario: Root
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    When the client successfully lists the directory "/"
-    Then the file list should be in long form
-    And the file list should contain "foo"
-    And the file list should contain "bar"
-
-  Scenario: Parent of root
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    When the client successfully lists the directory "/.."
-    Then the file list should be in long form
-    And the file list should contain "foo"
-    And the file list should contain "bar"
-
-  Scenario: Subdir
-    Given a successful login
-    And the server has file "subdir/foo"
-    When the client successfully lists the directory "subdir"
-    Then the file list should be in long form
-    And the file list should contain "foo"
-
-  Scenario: After CWD
-    Given a successful login
-    And the server has file "subdir/foo"
-    And the client successfully cd's to "subdir"
-    When the client successfully lists the directory
-    Then the file list should be in long form
-    And the file list should contain "foo"
-
-  Scenario: Glob
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    When the client successfully lists the directory "f*"
-    Then the file list should be in long form
-    And the file list should contain "foo"
-    And the file list should not contain "bar"
-
-  Scenario: Passive
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    And the client is in passive mode
-    When the client successfully lists the directory
-    Then the file list should be in long form
-    And the file list should contain "foo"
-    And the file list should contain "bar"
-
-  Scenario: -a
-    Given a successful login
-    And the server has file "foo"
-    And the server has file "bar"
-    When the client successfully lists the directory "-a"
-    Then the file list should be in long form
-    And the file list should contain "foo"
-    And the file list should contain "bar"
-
-  Scenario: Missing directory
-    Given a successful login
-    When the client successfully lists the directory "missing/file"
-    Then the file list should be empty
-
-  Scenario: Not logged in
-    Given a successful connection
-    When the client lists the directory
-    Then the server returns a not logged in error
-
-  Scenario: List not enabled
-    Given the test server lacks list
-    And a successful login
-    When the client lists the directory
-    Then the server returns an unimplemented command error