--user/--password and their --http-* aliases for Basic authentication,available to redirected hosts after their own Basic challenge;--auth-no-challenge sends these explicit credentials on every request,including cross-host redirects, as GNU Wget does;
response cookies shared across redirects and URL operands, Netscape--load-cookies/--save-cookies jars, --keep-session-cookies, and --no-cookies.
Default redirect rules remain Wget-specific: POST is rewritten on 301/302/303,other methods are retained, and 307/308 preserve method and body.
The workspace candidate percent-encodes raw ASCII space, TAB, CR, LF and DELin initial URL paths and queries using uppercase escapes. Already encodedbytes remain unchanged. Redirect Location spaces become %20 and TAB becomes%09 in both path and query. The calibrated complete-response cases succeed;this does not establish general browser URL normalization.
Network authorization belongs to the caller or host. The command does notembed an allowlist.
The workspace candidate retains partial response bytes. Fixed-length truncation,missing chunk-size lines and incomplete chunk payload CRLF report status 4when network retries are exhausted. The calibrated GNU profile accepts EOFinside an announced chunk's payload or while reading trailers, retaining alldelivered bytes. Retries reuse the actual selected filename and request the next byte after the already delivered prefix. A 206response must report that exact Content-Range before more output is written.When the server ignores Range with 200, the existing prefix is retained andthe repeated response prefix is discarded before the remaining bytes areappended. This preserves both streamed stdout and earlier URL output in ashared -O file. It does not verify that a server has kept the earlier prefixunchanged. Consumed stdin request bodies are not replayed on a retry. Thesechanges require the current candidate and exact published acceptance checks.A complete known-length 200 response shorter than the retained prefix leaves that prefixunchanged and succeeds. At the transfer layer, HTTP 416 succeeds without openingor changing output, including without a resume request and with missing ormalformed Content-Range, matching the fixed GNU observations. Explicit -Ofiles are initialized before transfers, so their earlier creation or truncationis separate from this response handling. Incorrect resumed 206 ranges fail withstatus 4 before appending bytes. Ordinary 304 responses return 8; timestampingtreats 304 as successful preservation of the existing file.
For GET with -c --content-disposition and no explicit -O, a HEAD requestfirst discovers the selected filename. Only then is that file's size used forthe GET resume offset; an unrelated URL-derived file does not supply the prefix.Discovery does not add an automatic resume Range, while an explicitly suppliedRange header remains a caller choice. GET retries retain the selected name.These request-order and file-effect contracts require the current fixed-oracleacceptance; they do not establish every method or redirect combination.
Requests default to Accept-Encoding: identity and preserve an explicitlysupplied header. Response content-coding bytes are written unchanged; retryoffsets refer to those encoded bytes. Automatic decompression is not enabled.Resumed bodies must match the Content-Range byte span even for chunked orclose-delimited responses without Content-Length. Bodyless responses do notconsume the retained prefix.
The pure MoonBit HTTP/1 adapter retains received chunk payload even when itsfollowing CRLF is missing or invalid. EOF after a complete 200 status lineaccepts completed headers and ignores the unfinished field; malformed completeheaders still fail before the transfer opens output. Explicit -O initializationstill occurs earlier. The shared transfer profile recordsprotocol metadata limits and framing support; these are project support choices.
This remains a bounded HTTP transfer profile, not full Wget compatibility.Recursive mirroring, FTP, non-Basic authentication/HSTS, post-download timestamprestoration, exact GNU progress and diagnostic bytes, and options outside thedocumented package help are not claimed.
Version 0.2.1 lets an explicit --header='Cookie: ...' replacethe outgoing jar cookie field, including across origins, as in GNU Wget 1.25.0.The jar still receivesresponse cookies. This correction is included in 0.2.1; historical 0.2.0 is unchanged.Cookie matching includes host/domain boundaries, path order, Secure, Max-Age,Expires, replacement and deletion. Public-suffix database and IDNA behaviorremain project implementation gaps. A challenge cannot replay an alreadyconsumed stdin request body and fails explicitly; file and in-memory bodiescan be replayed. As in GNU Wget, cookie-jar write failures do not change thetransfer exit status; non-quiet runs print a diagnostic.
The workspace candidate ignores a response Set-Cookie field without =without failing an otherwise complete body. A replacement with nonnumericMax-Age is ignored, preserving the matching stored cookie. Positive decimaloverflow with fewer than 32 digits instead expires that cookie, including itsprevious value; overlong attributes discard the replacement. Outgoing cookiessort by descending domain and path byte length, then name and value byte order.Repeated fields are processed in response order. Final response header observations retainSet-Cookie field names, values and order separately from parsed storage, withHTTP optional whitespace normalized; interim response cookies are not retained.These corrections require fresh Native/Wasm and fixed-oracle acceptance; theydo not establish byte-for-byte cookie-jar serialization parity.
Standalone --version prints exactly wget 0.2.3 followed by onenewline. Standalone --help starts with Usage: wget, lists bothmetadata options, and ends with a newline. Both write to stdout, leave stdinunread, and exit with status 0. Exact-version publication and verificationremain recorded separately in the support record.