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: --etag-save overwrites on status 304
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Mon, 2 Oct 2023 14:42:13 -0400
On 02-Oct-23 14:03, Paul Gilmartin via curl-users wrote:
> On 10/2/23 11:33:36, Timothe Litt via curl-users wrote:
>>>
>> Curl should write the ETag header received with the 304. Is the
>> server sending it?
>>
> It did not.
>
>> If not, it's a server bug.
>>
>> Note RFC2616 REQUIRES ETag to be sent "if it would have been sent in
>> a 200 response to the same request".
>>
> That's a weird contrafactual statement. The server could not have
> "sent ... a 200 response to the same request" because the "if none
> match would have required the 304. Should the RFC be amended?
>
> I read <https://datatracker.ietf.org/doc/html/rfc2616#section-14.26>:
> ... the server SHOULD
> respond with a 304 (Not Modified) response, including the cache-
> related header fields (particularly ETag) of one of the entities that
> matched. ...
>
> How does SHOULD differ from MUST?
>
>> If the server is sending it, but curl isn't writing it to the
>> --etag-save, it's a curl bug.
>
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
P.S. Remember that if-none-match can list several acceptable ETags,
which may refer to more than one locally cached instance of the
resource. The response tells you which one matched, and thus which
cached resource (file) you can use.
Also note that if you didn't include a *match* header, but did have a
*modified* header, the response may contain an ETag header, which
save-etags should record. E.g. If-Modified-Since (without an
If-None-Match) can also return a 304, with an ETag (and a LastModified).
Finally, note that a 304 response doesn't have to return ALL the headers
of a 200, so the client needs to save any that it needs on the initial
response and replace any that it cares about and are updated by the
304. You may not care when fetching some bytes to a simple file
system, but those file systems that retain a lot of metadata may.
Browsers often do care.
The RFCs consider lots of non-obvious cases...
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2023-10-02
Date: Mon, 2 Oct 2023 14:42:13 -0400
On 02-Oct-23 14:03, Paul Gilmartin via curl-users wrote:
> On 10/2/23 11:33:36, Timothe Litt via curl-users wrote:
>>>
>> Curl should write the ETag header received with the 304. Is the
>> server sending it?
>>
> It did not.
>
>> If not, it's a server bug.
>>
>> Note RFC2616 REQUIRES ETag to be sent "if it would have been sent in
>> a 200 response to the same request".
>>
> That's a weird contrafactual statement. The server could not have
> "sent ... a 200 response to the same request" because the "if none
> match would have required the 304. Should the RFC be amended?
>
> I read <https://datatracker.ietf.org/doc/html/rfc2616#section-14.26>:
> ... the server SHOULD
> respond with a 304 (Not Modified) response, including the cache-
> related header fields (particularly ETag) of one of the entities that
> matched. ...
>
> How does SHOULD differ from MUST?
>
>> If the server is sending it, but curl isn't writing it to the
>> --etag-save, it's a curl bug.
>
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
P.S. Remember that if-none-match can list several acceptable ETags,
which may refer to more than one locally cached instance of the
resource. The response tells you which one matched, and thus which
cached resource (file) you can use.
Also note that if you didn't include a *match* header, but did have a
*modified* header, the response may contain an ETag header, which
save-etags should record. E.g. If-Modified-Since (without an
If-None-Match) can also return a 304, with an ETag (and a LastModified).
Finally, note that a 304 response doesn't have to return ALL the headers
of a 200, so the client needs to save any that it needs on the initial
response and replace any that it cares about and are updated by the
304. You may not care when fetching some bytes to a simple file
system, but those file systems that retain a lot of metadata may.
Browsers often do care.
The RFCs consider lots of non-obvious cases...
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature