curl treats `-T -` as blocking stdin and `-T .` as non-blocking stdin, read incrementally during the transfer (each read chunk becomes an upload chunk; for WebSocket each chunk becomes one BINARY frame). urlx reads stdin to EOF at argument-parse time for both forms, so:
- `urlx -T . ws://echo.example/` blocks on a terminal stdin before even connecting, where curl connects immediately and sends data as it is typed;
- interactive/streaming uploads cannot interleave with downloads.
This matches urlx's existing buffered-upload architecture (curl test 2300 passes because its stdin is empty), but a streaming upload source would be needed for full fidelity. Related minor divergence: mixing per-URL `-T file` with `-T .`/`-T -` in multi-URL invocations does not replicate curl's per-URL association exactly (review finding on crates/urlx-cli/src/transfer.rs run_multi).
curl treats `-T -` as blocking stdin and `-T .` as non-blocking stdin, read incrementally during the transfer (each read chunk becomes an upload chunk; for WebSocket each chunk becomes one BINARY frame). urlx reads stdin to EOF at argument-parse time for both forms, so:
This matches urlx's existing buffered-upload architecture (curl test 2300 passes because its stdin is empty), but a streaming upload source would be needed for full fidelity. Related minor divergence: mixing per-URL `-T file` with `-T .`/`-T -` in multi-URL invocations does not replicate curl's per-URL association exactly (review finding on crates/urlx-cli/src/transfer.rs run_multi).