### FTP MLSD Command Syntax and Examples

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Illustrates the syntax and usage of the MLSD command for retrieving directory listings. Examples cover listing a directory with standard facts and more complex scenarios.

```ftp
MLSD .

```

```ftp
MLSD dir/subdir

```

```ftp
MLSD dir (type;modify;size)

```

--------------------------------

### MLSD Command: Example from Another Server

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Presents an MLSD command example from a different FTP server, demonstrating variations in output formatting and directory structure presentation. This example shows listing of 'IMAGE' and 'Binary' modes.

```ftp-cli
C> MlsD
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150227;perm=el; /MISC
D> type=pdir;modify=19791231130000;perm=el; /
D> type=dir;modify=19990426150227;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; SRC
S> 226 Transfer finished successfully.
C> MlsD src
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=1
```

--------------------------------

### FTP MLST Command Syntax and Examples

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Demonstrates the syntax and usage of the MLST command for requesting specific file properties. It includes examples of simple requests and requests for detailed information.

```ftp
MLST .

```

```ftp
MLST filename.ext

```

```ftp
MLST filename.ext(type;modify;size;unique)

```

--------------------------------

### FTP SIZE Command Examples

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Provides practical examples of using the FTP SIZE command with different transfer types (TYPE I and TYPE A). It shows how the reported file size can change based on the type, accounting for line ending differences.

```ftp-session
C> TYPE I
S> 200 Type set to I.
C> size Example
S> 213 1830
C> TYPE A
S> 200 Type set to A.
C> Size Example
S> 213 1942
```

--------------------------------

### FEAT Command Response Examples

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Examples of FEAT command responses illustrating the features and facts supported by an FTP server, including MLST capabilities.

```APIDOC
## GET /feat

### Description
Retrieves a list of supported features and extensions by the FTP server.

### Method
GET

### Endpoint
/feat

### Response
#### Success Response (200)
- **features** (array) - A list of supported FTP features and extensions.

#### Response Example
```json
{
  "example": "211- Features supported\n S> REST STREAM\n S> MDTM\n S> SIZE\n S> TVFS\n S> UTF8\n S> MLST Type\*;Size\*;Modify\*;Perm\*;Unique\*;UNIX.mode;UNIX.chgd;X.hidden;\n211 End"
}
```

```json
{
  "example": "211- Features supported\n S> MDTM\n S> MLST Type\*;Size\*;Modify\*;Perm;Unique\*;\n S> REST STREAM\n S> SIZE\n S> TVFS\n211 End"
}
```
```

--------------------------------

### FTP REST Command Example for Resuming Transfers

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

This example demonstrates the sequence of FTP commands to resume a partially transferred file. It includes setting the transfer type to binary, establishing a data connection, issuing the REST command with the byte offset, and then retrieving the file.

```ftp
C> TYPE I
S> 200 Type set to I.
C> PORT 127,0,0,1,15,107
S> 200 PORT command successful.
C> REST 802816
S> 350 Restarting at 802816. Send STORE or RETRIEVE
C> RETR cap60.pl198.tar
S> 150 Opening BINARY mode data connection
S> 226 Transfer complete.
```

--------------------------------

### TVFS Feature Response Example

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Illustrates a typical response from an FTP server that implements the TVFS feature when the FEAT command is issued. It shows the 'TVFS' feature line within the response.

```ftp-protocol
C> feat
S> 211- 
S> ...
S> TVFS
S> ...
S> 211 end
```

--------------------------------

### MLST Command Example

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Demonstrates the MLST command, which provides data about a specific object named on the command line. The response format is strictly defined and extensible.

```ftp-protocol
# Example assuming current directory is /A and 'C' is a directory
C> mlst C
S> 250-begin
S> type=dir;create=20020314153000;modify=20020314153000;<NLST>
S> 250 end
```

--------------------------------

### MLSD Command - Complex Example with Unique Fact

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Illustrates a more complex MLSD usage, including the 'Unique' fact and handling of various file types and permissions.

```APIDOC
## MLSD test

### Description
Lists directory contents with 'Unique' fact and details OS-dependent types and permissions.

### Method
FTP Command

### Endpoint
MLSD [directory_path]

### Parameters
#### Query Parameters
- **directory_path** (string) - Required - The path to the directory to list.

### Request Example
```
C> MLSD test
```

### Response
#### Success Response (150)
- **Type** (string) - Type of the entry (e.g., 'dir', 'file', 'OS.unix').
- **Perm** (string) - Permissions for the entry.
- **Unique** (string) - A unique identifier for the entry.
- **OS.unix** (string) - OS-specific type information (e.g., 'slink:/foobar').

#### Response Example
```
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
D> Type=file;Perm=awr;Unique=keVO1+8G4; writable
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous
S> 226 MLSD completed
```
```

--------------------------------

### HTTP Methods Testing

Source: https://httpbin.org/

This section covers endpoints for testing different HTTP verbs (GET, POST, PUT, DELETE, etc.).

```APIDOC
## GET /anything

### Description
Returns anything that is passed to the request. This is useful for inspecting the request data.

### Method
GET

### Endpoint
/anything

### Parameters
None

### Request Example
(No specific request body for GET, but demonstrates passing parameters)

### Response
#### Success Response (200)
- **data** (object) - The data received in the request.
- **headers** (object) - The headers received in the request.
- **origin** (string) - The origin IP address of the request.
- **url** (string) - The URL of the request.

#### Response Example
```json
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org"
  },
  "json": null,
  "origin": "127.0.0.1",
  "url": "http://httpbin.org/anything"
}
```
```

--------------------------------

### FTP OPTS Parameters for MLST

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Details how clients can use the OPTS command to specify parameters for MLST requests, allowing for more control over the information returned. Includes an example of the server's response.

```ftp
OPTS MLST type;size;modify

```

```ftp
200 OPTS MLST parameters accepted.

```

--------------------------------

### Free Pascal popcnt Implementation

Source: https://en.wikipedia.org/wiki/Hamming_weight

This example shows how Free Pascal implements the `popcnt` functionality, typically leveraging processor instructions for efficiency. Support for `popcnt` was introduced in version 3.0.

```pascal
var
  val: Cardinal;
  count: Integer;
begin
  val := 12345;
  count := popcnt(val);
end;
```

--------------------------------

### MLSD Command Example

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Shows the MLSD command, used to list the contents of a directory. If a non-directory object is named, a 501 reply is returned. If no object is named, the current directory's contents are listed.

```ftp-protocol
# Example listing contents of current directory
C> mlsd
S> 250-begin
S> type=dir;create=20020314153000;modify=20020314153000;.
S> type=dir;create=20020314153100;modify=20020314153100;C
S> type=file;size=1024;create=20020314153200;modify=20020314153200;Z
S> 250 end
```

--------------------------------

### MLSD Case In/Dependence Example

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Illustrates how the MLSD command and its labels are case-independent, while file names and unique identifiers can be case-dependent. This behavior depends on the server's file system implementation (NVFS).

```ftp-cli
C> MlsD
S> 150 BINARY connection open for MLSD .
D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
S> 226 MLSD completed
```

--------------------------------

### FTP SIZE Command Response Formats

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Specifies the expected response formats for the FTP SIZE command. A successful response starts with '213' followed by the file size and CRLF. Error responses are also defined, with specific codes for different issues.

```ftp-response
213 SP 1*DIGIT CRLF
```

```ftp-error-response
550 / 500 / 501 / 4xy
```

--------------------------------

### C++ std::bitset::count() Method

Source: https://en.wikipedia.org/wiki/Hamming_weight

This example shows how to use the `count()` method of the C++ `std::bitset` class to determine the number of set bits within a bitset. The `bitset` must be initialized with a size, and `count()` returns a `size_t` representing the number of '1's.

```cpp
std::bitset<64> myBitset("11010110");
size_t setBits = myBitset.count();
```

--------------------------------

### Fortran 2008 popcnt Intrinsic Function

Source: https://en.wikipedia.org/wiki/Hamming_weight

This Fortran example utilizes the `popcnt` intrinsic function, standardized in Fortran 2008. It returns the number of non-zero bits in an integer or an array of integers.

```fortran
integer :: my_int = 42
integer :: bit_count
bit_count = popcnt(my_int)
```

--------------------------------

### Java Integer.bitCount() Method

Source: https://en.wikipedia.org/wiki/Hamming_weight

This Java example shows the use of the static `Integer.bitCount(int)` method, which returns the number of one-bits in the two's complement binary representation of the specified `int` value. A similar method `Long.bitCount(long)` exists for `long` values.

```java
int value = 42;
int setBits = Integer.bitCount(value);
```

--------------------------------

### Common Lisp logcount Function

Source: https://en.wikipedia.org/wiki/Hamming_weight

This Common Lisp example shows the `logcount` function, which returns the number of set bits (1s) in the binary representation of a non-negative integer. For negative integers, it returns the number of zero bits in their two's complement representation.

```lisp
(logcount 42)
```

--------------------------------

### Auth Methods

Source: https://httpbin.org/

Endpoints related to authentication methods.

```APIDOC
## GET /basic-auth/{user}/{passwd}

### Description
Provides basic HTTP authentication.

### Method
GET

### Endpoint
/basic-auth/{user}/{passwd}

### Parameters
#### Path Parameters
- **user** (string) - Required - The username for authentication.
- **passwd** (string) - Required - The password for authentication.

### Request Example
(No specific request body for GET)

### Response
#### Success Response (200)
- **authenticated** (boolean) - True if authentication was successful.
- **user** (string) - The authenticated username.

#### Response Example
```json
{
  "authenticated": true,
  "user": "testuser"
}
```
```

--------------------------------

### MLSD Command - Basic Usage

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Demonstrates the basic usage of the MLSD command to list the contents of a directory and explains the output format, including facts like Type, Modify, and Perm.

```APIDOC
## MLSD /tmp

### Description
Lists the contents of the specified directory with detailed facts about each item.

### Method
FTP Command

### Endpoint
MLSD [directory_path]

### Parameters
#### Query Parameters
- **directory_path** (string) - Required - The path to the directory to list.

### Request Example
```
C> MLSD tmp
```

### Response
#### Success Response (150)
- **Type** (string) - Type of the directory entry (e.g., 'cdir', 'pdir', 'file').
- **Modify** (string) - Modification timestamp (YYYYMMDDHHMMSS).
- **Perm** (string) - Permissions for the entry.
- **Size** (integer) - Size of the file in bytes.

#### Response Example
```
S> 150 BINARY connection open for MLSD tmp
D> Type=cdir;Modify=19981107085215;Perm=el; tmp
D> Type=cdir;Modify=19981107085215;Perm=el; /tmp
D> Type=pdir;Modify=19990112030508;Perm=el; ..
D> Type=file;Size=25730;Modify=19940728095854;Perm=;
capmux.tar.z
D> Type=file;Size=1830;Modify=19940916055648;Perm=r;
hatch.c
S> 226 MLSD completed
```
```

--------------------------------

### Redirects

Source: https://httpbin.org/

Endpoints for returning different redirect responses.

```APIDOC
## GET /redirect/{n}

### Description
Performs a series of redirects.

### Method
GET

### Endpoint
/redirect/{n}

### Parameters
#### Path Parameters
- **n** (integer) - Required - The number of redirects to perform.

### Request Example
(No specific request body for GET)

### Response
#### Success Response (302)
(Redirects to the specified number of times.)

#### Response Example
(No specific JSON response body, as it's a redirect)
```

--------------------------------

### MLSD Command: Listing Directory Contents

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Demonstrates the basic usage of the MLSD command to list directory contents. The output includes file types, modification times, sizes, and permissions. Server-side implementations may vary in how they handle case sensitivity for file names and labels.

```ftp-cli
C> MLSD
S> 226 MLSD completed
C> MLSD character-set-info
S> 150 BINARY connection open for MLSD character-set-info
D> Type=cdir;Modify=19990112033515; character-set-info
D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info
D> Type=pdir;Modify=19990219183438; ..
D> Type=file;Size=1234;Modify=19980903020400; windows-1251
D> Type=file;Size=4557;Modify=19980922001400; tis-620
D> Type=file;Size=801;Modify=19970324130000; ibm775
D> Type=file;Size=552;Modify=19970320130000; ibm866
D> Type=file;Size=922;Modify=19960505140000; windows-1258
S> 226 MLSD completed
C> MLSD languages
S> 150 BINARY connection open for MLSD languages
D> Type=cdir;Modify=19990112033529; languages
D> Type=cdir;Modify=19990112033529; /iana/assignments/languages
D> Type=pdir;Modify=19990219183438; ..
D> Type=file;Size=2391;Modify=19980309130000; default
D> Type=file;Size=943;Modify=19980309130000; tags
D> Type=file;Size=870;Modify=19971026130000; navajo
D> Type=file;Size=699;Modify=19950911140000; no-bok
S> 226 MLSD completed
C> PWD
S> 257 "/iana/assignments" is current directory.
```

--------------------------------

### FTP FEAT Command Support for SIZE

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Illustrates how an FTP server indicates support for the SIZE command when responding to the FEAT (Features) command. The server must include 'SIZE' in its list of supported features.

```ftp-feat-response
S> 211- 
S> ... 
S> SIZE 
S> ... 
S> 211 END
```

--------------------------------

### FTP SIZE Command Syntax

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Defines the syntax for the FTP SIZE command. It expects the keyword 'Size' followed by a pathname and a carriage return line feed. The server responds with a 213 status code and the file's transfer size, or an error.

```ftp-command
SIZE SP pathname CRLF
```

--------------------------------

### Images

Source: https://httpbin.org/

Endpoints for returning different image formats.

```APIDOC
## GET /image/png

### Description
Returns a PNG image.

### Method
GET

### Endpoint
/image/png

### Parameters
None

### Request Example
(No specific request body for GET)

### Response
#### Success Response (200)
(Returns a PNG image binary stream.)

#### Response Example
(Binary image data)
```

--------------------------------

### MLSD Command - Subdirectory Listing

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Shows how to list the contents of a subdirectory using the MLSD command.

```APIDOC
## MLSD test/incoming

### Description
Lists the contents of a subdirectory, providing details for files and nested directories.

### Method
FTP Command

### Endpoint
MLSD [directory_path]

### Parameters
#### Query Parameters
- **directory_path** (string) - Required - The path to the subdirectory to list.

### Request Example
```
C> MLSD test/incoming
```

### Response
#### Success Response (150)
- **Type** (string) - Type of the entry (e.g., 'cdir', 'file', 'dir').
- **Perm** (string) - Permissions for the entry.
- **Unique** (string) - A unique identifier for the entry.

#### Response Example
```
S> 150 BINARY connection open for MLSD test/incoming
D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming
D> Type=pdir;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar
D> Type=file;Perm=rf;Unique=keVO1+1G4; file5
D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty
S> 226 MLSD completed
```
```

--------------------------------

### Dynamic Data

Source: https://httpbin.org/

Endpoints for generating random and dynamic data.

```APIDOC
## GET /uuid

### Description
Returns a UUID (Universally Unique Identifier).

### Method
GET

### Endpoint
/uuid

### Parameters
None

### Request Example
(No specific request body for GET)

### Response
#### Success Response (200)
- **uuid** (string) - A randomly generated UUID.

#### Response Example
```json
{
  "uuid": "a7b3b1b0-3b1e-4b1d-8b1e-3b1e4b1d8b1e"
}
```
```

--------------------------------

### Cookies

Source: https://httpbin.org/

Endpoints for creating, reading, and deleting cookies.

```APIDOC
## GET /cookies/set

### Description
Sets a cookie in the response.

### Method
GET

### Endpoint
/cookies/set

### Parameters
#### Query Parameters
- **name** (string) - Required - The name of the cookie.
- **value** (string) - Required - The value of the cookie.

### Request Example
(No specific request body for GET)

### Response
#### Success Response (200)
- **cookies** (object) - A dictionary of cookies set by the response.

#### Response Example
```json
{
  "cookies": {
    "mycookie": "myvalue"
  }
}
```
```

--------------------------------

### Recursive Popcount Lookup Table Initialization (C)

Source: https://en.wikipedia.org/wiki/Hamming_weight

An alternative C function to initialize the popcount lookup table `wordbits`. This recursive approach calculates the bit count for an integer based on the bit count of its half-shifted value and its least significant bit. This method is efficient for filling the table.

```c
int popcount32e_init (void) {
  int i;
  for (i = 1; sizeof wordbits / sizeof *wordbits > i; ++i)
    wordbits[i] = wordbits[i >> 1] + (1 & i);
}
```

--------------------------------

### Response Formats

Source: https://httpbin.org/

Endpoints for returning responses in different formats (JSON, XML, HTML, etc.).

```APIDOC
## GET /json

### Description
Returns a JSON response.

### Method
GET

### Endpoint
/json

### Parameters
None

### Request Example
(No specific request body for GET)

### Response
#### Success Response (200)
- **slideshow** (object) - A JSON object containing slideshow data.

#### Response Example
```json
{
  "slideshow": {
    "author": "Yours Truly",
    "date": "date of publication",
    "slides": [
      {
        "title": "Wake up to WonderWidgets!",
        "type": "all"
      },
      {
        "items": [
          "Why <em>WonderWidgets</em> are great",
          "Who <em>buys</em> WonderWidgets"
        ],
        "title": "Overview",
        "type": "all"
      }
    ],
    "title": "Sample Slide Show"
  }
}
```
```

--------------------------------

### FTP FEAT Response for MLST/MLSD

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Shows how a server indicates support for MLST and MLSD commands via the FEAT response. This includes the specific parameters and facts supported.

```ftp
211-Features:
 MDTM
 REST
 SIZE
 MLST type*;size*;modify*;perm*;unique*;UNIX.mode;
 MLSD type*;size*;modify*;perm*;unique*;UNIX.mode;
 End of features

```

--------------------------------

### URI Component Recomposition (Pseudocode)

Source: https://tools.ietf.org/html/rfc3986

This pseudocode illustrates how to recompose a URI reference string from its parsed components (scheme, authority, path, query, fragment). It handles the conditional appending of components and their respective separators.

```pseudocode
function recompose_uri(scheme, authority, path, query, fragment):
    result = ""
    if defined(scheme):
        append scheme to result
        append ":" to result
    endif
    if defined(authority):
        append "//" to result
        append authority to result
    endif
    append path to result
    if defined(query):
        append "?" to result
        append query to result
    endif
    if defined(fragment):
        append "#" to result
        append fragment to result
    endif
    return result
```

--------------------------------

### MLST/MLSD Command Syntax

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Defines the syntax for the MLST and MLSD commands, including optional pathnames.

```APIDOC
## MLST/MLSD Command Syntax

### Description
Defines the syntax for the MLST and MLSD commands, which are used to retrieve information about files and directories.

### Method
FTP Command

### Endpoint
N/A (FTP commands operate over the control connection)

### Parameters
#### Pathname (Optional)
- **pathname** (string) - Optional - The name of the directory or file to retrieve information about. If omitted, information about the current working directory is returned.

### Syntax Rules
- `mlst = "MLst" [ SP pathname ] CRLF`
- `mlsd = "MLsD" [ SP pathname ] CRLF`

### Example
```
MLST /path/to/file.txt
MLSD
```
```

--------------------------------

### Initializing Popcount Lookup Table (C)

Source: https://en.wikipedia.org/wiki/Hamming_weight

This C function initializes a lookup table for 16-bit integers, which can then be used by `popcount32e`. It iterates through all possible 16-bit values and calculates their population count using the `popcount64d` principle (iteratively unsetting the least significant bit).

```c
int popcount32e_init(void) {
  uint32_t i;
  uint16_t x;
  int count;
  for (i = 0; i <= 0xFFFF; i++) {
    x = i;
    for (count = 0; x; count++)
      x &= x - 1;
    wordbits[i] = count;
  }
}
```

--------------------------------

### URI Reference Transformation Algorithm

Source: https://tools.ietf.org/html/rfc3986

This pseudocode describes the algorithm for transforming a URI reference (R) into its target URI (T) based on a given base URI. It handles different cases, including the presence or absence of scheme, authority, and path components in the reference, and applies dot segment removal.

```pseudocode
-- The URI reference is parsed into the five URI components --
(R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);

-- A non-strict parser may ignore a scheme in the reference --
-- if it is identical to the base URI's scheme. --
if ((not strict) and (R.scheme == Base.scheme)) then
  undefine(R.scheme);
endif;

if defined(R.scheme) then
  T.scheme = R.scheme;
  T.authority = R.authority;
  T.path = remove_dot_segments(R.path);
  T.query = R.query;
else if defined(R.authority) then
  T.authority = R.authority;
  T.path = remove_dot_segments(R.path);
  T.query = R.query;
else if (R.path == "") then
  T.path = Base.path;
  if defined(R.query) then
    T.query = R.query;
  else
    T.query = Base.query;
  endif;
else if (R.path starts-with "/") then
  T.path = remove_dot_segments(R.path);
else
  T.path = merge(Base.path, R.path);
  T.path = remove_dot_segments(T.path);
endif;

  T.query = R.query;
endif;

T.authority = Base.authority;
endif;

T.scheme = Base.scheme;
endif;

T.fragment = R.fragment;
```

--------------------------------

### MLST Command Usage

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

The MLST command is used to list directory contents with specific facts (metadata) about each file or directory. The server indicates supported facts via the FEAT command.

```APIDOC
## GET /mlst

### Description
Lists directory contents with specified facts about each item. The available facts are indicated by the server's response to the FEAT command.

### Method
GET

### Endpoint
/mlst

### Parameters
#### Query Parameters
- **facts** (string) - Optional - A semicolon-separated list of facts to be returned for each listed item (e.g., `type;size;modify`).

### Request Example
```
C> MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden
```

### Response
#### Success Response (200)
- **facts** (string) - The metadata for each file/directory, formatted according to the requested facts.
- **filename** (string) - The name of the file or directory.

#### Response Example
```json
{
  "example": "211- MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden; \n 211 End"
}
```
```

--------------------------------

### Status Codes

Source: https://httpbin.org/

Endpoints for generating responses with specific HTTP status codes.

```APIDOC
## GET /status/{code}

### Description
Generates a response with the specified HTTP status code.

### Method
GET

### Endpoint
/status/{code}

### Parameters
#### Path Parameters
- **code** (integer) - Required - The HTTP status code to return (e.g., 200, 404, 500).

### Request Example
(No specific request body for GET)

### Response
#### Success Response ({code})
(The response content depends on the status code, typically an empty body or a simple message).

#### Response Example (for code 204)
(No content)
```

--------------------------------

### HTML Form POST

Source: https://httpbin.org/

An HTML form that posts data to the /post endpoint.

```APIDOC
## POST /forms/post

### Description
An HTML form that posts data to the /post endpoint. Use this to test form submissions.

### Method
POST

### Endpoint
/forms/post

### Parameters
#### Request Body
(This endpoint expects form-encoded data, similar to submitting an HTML form.)
- **field1** (string) - Optional - A form field.
- **field2** (string) - Optional - Another form field.

### Request Example
(Simulated form submission)
```
field1=value1&field2=value2
```

### Response
#### Success Response (200)
- **form** (object) - Form data parsed from the request.
- **data** (string) - Raw data from the request body.
- **headers** (object) - The headers received in the request.
- **origin** (string) - The origin IP address of the request.
- **url** (string) - The URL of the request.

#### Response Example
```json
{
  "args": {},
  "data": "",
  "files": {},
  "form": {
    "field1": "value1",
    "field2": "value2"
  },
  "headers": {
    "Accept": "*/*",
    "Content-Length": "25",
    "Content-Type": "application/x-www-form-urlencoded",
    "Host": "httpbin.org"
  },
  "json": null,
  "origin": "127.0.0.1",
  "url": "http://httpbin.org/post"
}
```
```

--------------------------------

### OPTS MLST Command Usage

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

The OPTS MLST command allows the client to specify a list of facts that should be returned in all subsequent MLST and MLSD commands until a new OPTS MLST command is issued.

```APIDOC
## POST /opts/mlst

### Description
Sets the preferred facts to be included in subsequent MLST and MLSD commands. If no fact names are provided, only file names will be returned.

### Method
POST

### Endpoint
/opts/mlst

### Parameters
#### Request Body
- **facts** (string) - Optional - A semicolon-separated list of fact names to be included in subsequent MLST/MLSD commands.

### Request Example
```
C> OPTS MLST Type;size;modify;UNIX.mode
```

### Response
#### Success Response (200)
- **message** (string) - Confirmation that the options have been set, listing the facts the server will now include.

#### Response Example
```json
{
  "example": "MLST OPTS Type;size;modify;UNIX.mode"
}
```
```

--------------------------------

### Java BitSet.cardinality() Method

Source: https://en.wikipedia.org/wiki/Hamming_weight

This Java code snippet illustrates how to use the `cardinality()` method of the `java.util.BitSet` class. This method returns the number of bits that are set to true in the `BitSet`.

```java
java.util.BitSet bits = new java.util.BitSet();
bits.set(1);
bits.set(3);
bits.set(5);
int setBits = bits.cardinality();
```

--------------------------------

### Remove Dot Segments Algorithm (Pseudocode)

Source: https://tools.ietf.org/html/rfc3986

This pseudocode describes a method for normalizing URI paths by removing '.' and '..' segments. It uses two string buffers (input and output) to process the path components. The algorithm handles various cases, including removing prefixes and managing the output buffer based on the input.

```pseudocode
function remove_dot_segments(input_path):
    input_buffer = input_path
    output_buffer = ""

    while input_buffer is not empty:
        if input_buffer begins with "../" or "./":
            remove prefix from input_buffer
        else if input_buffer begins with "/./" or "/.":
            replace prefix with "/" in input_buffer
        else if input_buffer begins with "/../" or "/..":
            replace prefix with "/" in input_buffer
            remove last segment and preceding "/" from output_buffer
        else if input_buffer is "." or "..":
            remove input_buffer
        else:
            move first path segment from input_buffer to end of output_buffer, including "/" if present

    return output_buffer
```

--------------------------------

### FTP REST Command for Stream Mode

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Explains the purpose of the FTP REST (Restart) command, particularly in STREAM mode. It allows resuming an interrupted file transfer from a specific point in the data stream, using a byte offset.

```ftp-command-description
REST marker
Where 'marker' is a byte offset for resuming transfer in STREAM mode.
```

--------------------------------

### MLST/MLSD Response Format

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

Details the structure and content of responses to MLST and MLSD commands, including success and error formats.

```APIDOC
## MLST/MLSD Response Format

### Description
Explains the format of responses returned by the server for MLST and MLSD commands, covering both successful data retrieval and error conditions.

### Method
FTP Response

### Endpoint
N/A (FTP responses are sent over the control connection)

### Response Structure

**MLST Response:**
```
mlst-response = control-response / error-response
control-response = "250-" [ response-message ] CRLF 1*( SP entry CRLF ) "250" [ SP response-message ] CRLF
response-message = *TCHAR
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
factname = "Size" / "Modify" / "Create" / "Type" / "Unique" / "Perm" / "Lang" / "Media-Type" / "CharSet" / os-depend-fact / local-fact
os-depend-fact = "." token
local-fact = "X." token
value = *SCHAR
```

**MLSD Response:**
```
mlsd-response = ( initial-response final-response ) / error-response
initial-response = "150" [ SP response-message ] CRLF
final-response = "226" SP response-message CRLF
response-message = *TCHAR
data-response = *( entry CRLF )
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
```

### Error Handling
- **501 Reply**: Returned if the Client-FTP sends an invalid argument or if the client does not have permission to perform the requested operation.
- **Error-Response**: General error response format.

### Response Example (MLST Success)
```
250- Size=1024;Modify=20230101000000;Perm=ad; Type=file; Unique=12345; /path/to/file.txt
250 OK
```

### Response Example (MLSD Success)
```
150 Opening data connection
Size=4096;Modify=20230101000000;Type=dir; /path/to/directory
226 Transfer complete
```
```

--------------------------------

### Response Inspection

Source: https://httpbin.org/

Endpoints for inspecting response details like caching and headers.

```APIDOC
## GET /response-headers

### Description
Returns response headers that were sent to the client.

### Method
GET

### Endpoint
/response-headers

### Parameters
#### Query Parameters
- **name** (string) - Optional - The name of the header to return.
- **value** (string) - Optional - The value of the header to return.

### Request Example
(No specific request body for GET)

### Response
#### Success Response (200)
- **headers** (object) - A dictionary of response headers.

#### Response Example
```json
{
  "headers": {
    "Content-Type": "application/json",
    "Server": "gunicorn/19.9.0"
  }
}
```
```

--------------------------------

### FTP FEAT Response for REST STREAM Support

Source: https://tools.ietf.org/html/draft-ietf-ftpext-mlst-16

This snippet shows how an FTP server indicates support for the REST command in STREAM mode via the FEAT command response. It includes the mandatory 'REST STREAM' line, noting it's case-insensitive but recommended in uppercase. If REST is not supported or only in other modes, this line is omitted.

```ftp
S> 211- 
S> ... 
S> REST STREAM 
S> ... 
S> 211 end
```

--------------------------------

### Request Inspection

Source: https://httpbin.org/

Endpoints for inspecting the data sent in the request.

```APIDOC
## POST /post

### Description
Inspects the data sent in a POST request, including form data, JSON, and files.

### Method
POST

### Endpoint
/post

### Parameters
#### Request Body
- **data** (any) - Optional - The data to be sent in the request body. Can be form-encoded or JSON.

### Request Example
```json
{
  "key": "value"
}
```

### Response
#### Success Response (200)
- **form** (object) - Form data parsed from the request.
- **json** (object) - JSON data parsed from the request.
- **data** (string) - Raw data from the request body.
- **headers** (object) - The headers received in the request.
- **origin** (string) - The origin IP address of the request.
- **url** (string) - The URL of the request.

#### Response Example
```json
{
  "args": {},
  "data": "{\"key\": \"value\"}",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Content-Length": "17",
    "Content-Type": "application/json",
    "Host": "httpbin.org"
  },
  "json": {
    "key": "value"
  },
  "origin": "127.0.0.1",
  "url": "http://httpbin.org/post"
}
```
```

--------------------------------

### GCC Built-in Popcount Function (C)

Source: https://en.wikipedia.org/wiki/Hamming_weight

This demonstrates the use of GCC's built-in `__builtin_popcount` function for calculating the population count. This function is highly optimized and will typically use a dedicated processor instruction if available, falling back to an efficient library implementation otherwise.

```c
int count = __builtin_popcount(some_unsigned_int);
```

--------------------------------

### RFC 3986 URI Parsing Regular Expression

Source: https://tools.ietf.org/html/rfc3986

This snippet presents a regular expression designed for parsing Uniform Resource Identifier (URI) references, as discussed in Appendix B of RFC 3986. This regex aims to capture the various components of a URI according to the generic syntax rules.

```Regex
(?:(?:[^:/?#]+):)?(?:(?:(?:[^@/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:(?:[^@/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^@/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?))?(?:(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?))?(?:(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?)|(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?))?(?:(?:[^/?#]*)(?:@)?)([^@/?#:]*)(?::(\d*))?))?(?:/(?<path>[^?#]*))?(?:\?(?<query>[^#]*))?(?:#(?<fragment>.*))?
```

--------------------------------

### RFC 3986 URI Generic Syntax ABNF Grammar

Source: https://tools.ietf.org/html/rfc3986

This snippet provides the Augmented Backus-Naur Form (ABNF) grammar for defining the structure of Uniform Resource Identifiers (URIs) as specified in RFC 3986. It covers the main components of a URI, including scheme, authority, path, query, and fragment.

```ABNF
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
URI-reference = URI / relative-ref
absolute-URI = scheme ":" hier-part [ "?" query ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = [ userinfo "@" ] host [ ":" port ]
host = IP-literal / IPv4address / reg-name
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT / "%x31-39" DIGIT / "1" 2DIGIT / "2" %x30-34 DIGIT / "25" %x30-35
reg-name = *( unreserved / pct-encoded / sub-delims )
path = path-abempty / path-absolute / path-noscheme / path-rootless / path-empty
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

```