curl / Mailing Lists / curl-users / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: File overwritten with HTTP/1.1 304 Not Modified

From: Paul Gilmartin via curl-users <>
Date: Tue, 3 Sep 2019 11:25:27 -0600

On 2019-09-03, at 03:10:25, Daniel Stenberg via curl-users <> 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.

Thanks again,

Received on 2019-09-03