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-compare vs. --time-cond
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Sat, 4 Mar 2023 15:59:42 -0500
On 04-Mar-23 15:12, Paul Gilmartin via curl-users wrote:
> If I specify both --etag-compare and --time-cond and they disagree on
> whether a file is up-to-date, which wins?
>
> (It might depend on the HTTPD)
RFC 7232 <https://www.rfc-editor.org/rfc/rfc7232> Section3.3 specifies
that the E-Tag wins for GET class requests.
> 3.3 <https://www.rfc-editor.org/rfc/rfc7232#section-3.3>.
> If-Modified-Since
>
> The "If-Modified-Since" header field makes a GET or HEAD request
> method conditional on the selected representation's modification date
> being more recent than the date provided in the field-value.
> Transfer of the selected representation's data is avoided if that
> data has not changed.
>
> If-Modified-Since = HTTP-date
>
> An example of the field is:
>
> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
>
> A recipient MUST ignore If-Modified-Since if the request contains an
> If-None-Match header field; the condition in If-None-Match is
> considered to be a more accurate replacement for the condition in
> If-Modified-Since, and the two are only combined for the sake of
> interoperating with older intermediaries that might not implement
> If-None-Match.
It's slightly more complicated in that there are rules about weak and
strong validators, and whether Last-Modified is weak or strong is a bit
subtle. You have to read the RFC to really understand how this works.
But the simple answer is E-Tag wins. Both are provided for
compatibility with older servers and older clients. Often LM is used
because generating a strong E-Tag can be expensive.
3.4 says the same for update class requests. such as POST or DELETE.
Again, there are subtleties worth understanding.
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-03-04
Date: Sat, 4 Mar 2023 15:59:42 -0500
On 04-Mar-23 15:12, Paul Gilmartin via curl-users wrote:
> If I specify both --etag-compare and --time-cond and they disagree on
> whether a file is up-to-date, which wins?
>
> (It might depend on the HTTPD)
RFC 7232 <https://www.rfc-editor.org/rfc/rfc7232> Section3.3 specifies
that the E-Tag wins for GET class requests.
> 3.3 <https://www.rfc-editor.org/rfc/rfc7232#section-3.3>.
> If-Modified-Since
>
> The "If-Modified-Since" header field makes a GET or HEAD request
> method conditional on the selected representation's modification date
> being more recent than the date provided in the field-value.
> Transfer of the selected representation's data is avoided if that
> data has not changed.
>
> If-Modified-Since = HTTP-date
>
> An example of the field is:
>
> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
>
> A recipient MUST ignore If-Modified-Since if the request contains an
> If-None-Match header field; the condition in If-None-Match is
> considered to be a more accurate replacement for the condition in
> If-Modified-Since, and the two are only combined for the sake of
> interoperating with older intermediaries that might not implement
> If-None-Match.
It's slightly more complicated in that there are rules about weak and
strong validators, and whether Last-Modified is weak or strong is a bit
subtle. You have to read the RFC to really understand how this works.
But the simple answer is E-Tag wins. Both are provided for
compatibility with older servers and older clients. Often LM is used
because generating a strong E-Tag can be expensive.
3.4 says the same for update class requests. such as POST or DELETE.
Again, there are subtleties worth understanding.
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