Re: File overwritten with HTTP/1.1 304 Not Modified

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.

Thanks again,
gil

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-09-03