Re: File overwritten with HTTP/1.1 304 Not Modified
Date: Tue, 3 Sep 2019 11:25:27 -0600
On 2019-09-03, at 03:10:25, Daniel Stenberg via curl-users <curl-users_at_cool.haxx.se> wrote:
> On Sat, 31 Aug 2019, Paul Gilmartin via curl-users wrote:
>> *however* my --output file is overwritten with an empty file.
>> I'd prefer that this not happen.
>> Is there a combination of options that preserves the file in case of 304? Should I consider this a bug?
>> I believe an earlier release of curl on Raspberry Pi did not overwrite.
> I believe we may have at some point changed the behavior slightly on writing a zero byte body - but I can't remember why. I don't think this is 304 specific but works the same no matter which response code.
Thanks. I've now searched and found Issue #382 discussing this topic.
It explains why sincere minds may differ.
> The question of course remains what the "correct" behavior is. A zero byte file could very well be interpreted as the correct way to represent a zero byte response body...
>> I understand that in case of some errors, such as 404, the user prefers to receive the file.
> 1. curl will of course save the response body for any response code, but 304s are special as they are defined to never have a body.
Alas, HTTP provides no way to distinguish absent body from empty body.
Absence of "Content-Length:" header may not be probative.
> 2. --fail will make curl not save the 404 response body
Which is not relevant to me because 304 is not an error.
o I'm switching to --time-cond <previously-fetched-file>
o But I need to treat the first fetch as a special case.
o I won't worry much about a timing window's making the
file on the server falsely appear older.