[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — ran pylint/mypy/isort on the touched files: no new findings (httpv1.py's isort complaint and the existing pylint design warnings predate this)
• make test passes, and a test case covers the change — modules listed below, not the full suite
• Added a changelog entry — N/A, added centrally

What is the purpose of your pull request?

• fix — corrects a defect

---

Description

Closes #1238
Closes #1239
Closes #1240
Closes #1241

FTP make appends CRLF, omits the separator when args is None and after a reply hyphen (RFC 959 §4.2). Only the single SP is syntax, so USER x, 220- x and QUIT keep their bytes. \Z replaces $. For #1241, text that would not re-encode as UTF-8 records the detected charset (or latin-1 as a fallback). protocol.py's chardet decoding is unchanged, and the displayed str is the same as before.

Breaking: FTP Request/Response and HTTP/1 RequestHeader/ResponseHeader have a new required charset field. FTP args is None for argument-less lines. 220- Ready now parses to args=' Ready', which updates the existing pin in test_ftp_unit.py. make also accepts charset.

Probe: before the fix, USER anonymous\r\n raises ProtocolError, QUIT\r\n raises TypeError, 220-Welcome\r\n raises ProtocolError, and GET /caf\xe9 rebuilds as /caf\xc3\xa9. After it, all of them plus the latin-1 FTP and HTTP reason phrase rebuild byte-exactly. All 241 HTTP layers in examples/captures/* round-trip, both before and after.

Tests: test_ftp_http1_roundtrip_unit passes 8/8 with 16 subtests; with the fix reverted, 5 tests and 15 subtests fail (only the UTF-8 HTTP control passes). test_ftp_unit 10, test_http_unit 65, test_http_runtime 5, test_http_from_data_1154 4, test_option_roundtrip 6, tests/project 389 passed. The run_unittest_leg.py protocols --exclude protocols/internet leg ran 858 tests, OK.

Out of scope: HTTP/1 header field values are still re-encoded as UTF-8, and a multi-line FTP reply in one segment still fails to parse.

[github-actions]

Coverage: 88.90% (unit tier, Python 3.14, 4a60fb89f, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18757	1034	2342	845	90.24%
pcapkit/corekit	1878	91	580	22	94.34%
pcapkit/dumpkit	142	0	42	0	100.00%
pcapkit/foundation	2442	102	852	39	94.38%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	15802	196	4046	167	98.14%
pcapkit/toolkit	487	65	144	1	85.42%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2359	1006	158	42.84%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

Cross-review verdict on 4a60fb89f: GOOD TO GO (Sonnet reviewed; the author ran on Opus).

• Repros: every fix(ftp): make never appends CRLF, so no FTP packet rebuilds #1238–fix(protocols): non-UTF-8 octets in FTP args and HTTP/1 start lines are re-encoded as UTF-8 on rebuild #1241 repro fails on main and now rebuilds byte-exactly. I re-ran the USER, QUIT, 220- and latin-1 GET cases myself.
• RFC 959 §4.2: text follows the hyphen directly (123-First line), so 220- Ready correctly parses with the text ' Ready'.
• Charset fuzz: across about 14,000 FTP and HTTP/1 inputs (invalid UTF-8, latin-1, cp1251, shift_jis, gbk, mixed), no failure comes from the new charset field.
• Fixtures: all 231 HTTP layers parse the same as on main, apart from the new key, and rebuild exactly. Dumps with args=None succeed.
• Tests and CI: the new tests fail without the fix. The leg runs 858 tests with 0 failures.
• Out of scope here, filed separately:
  • FTP command case is still normalised (Command.get raises TypeError on the first lowercase FTP command, so a valid RFC 959 request cannot be parsed #582).
  • HTTP/1 start lines lose ASCII whitespace at field edges.