3 ms·

You always have to handle exceptions, but if you can insist on early 3xx/4xx (at least 401) responses, then you can avoid caching any part of the request body.

You always have to handle exceptions, but if you can insist on early 3xx/4xx (at least 401) responses, then you can avoid caching any part of the request body. For example, consider something like: $ huge_fast_source | curl --negotiate -x POST ... Here curl might respond to 401s by authenticating to the server, and if it can know that a 401 is coming, then it can simply not read from stdin (thus flow-controlling the huge, fast source) until it has seen 100-continue, which might require a second request. This is very nice. The fact that it can't be had reliably is rather annoying.

jayd16 8y ago
I see your hypothetical but I can't its something I've missed. If reads are not repeatable or can't be lost then you really should caching them. If you can reset your stream, then just start the firehose. Presumably things like a 401 are rare so the waste is minimal. I could see a use case for this when network IO is prohibitively expensive and needs to be minimized. You're right that there isn't a great solution.