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: Sun, 5 Mar 2023 08:15:32 -0500
On 04-Mar-23 23:24, Paul Gilmartin via curl-users wrote:
> On 3/4/23 15:41:44, Timothe Litt via curl-users wrote:
>
>> ...
>> Section 6 also discusses precedence and evaluation order.
>>
>> As I said, read the whole RFC.
>>
>> Your test isn't valid. An E-Tag validator is only meaningful to the
>> server that sent it.
>> ...
>> For example, consider a validator that internally looks like
>> <mtime>-<size>-<expires>. If the server doesn't keep a side database
>> of validators, it might try to parse it, and since "wombat" isn't in
>> that format, give up.
>
> I'm calling it the site. Another URL on a different site let ETag
> dominate
> and didn't give up on "wombat", not calling it a matcn.
>
It's not the site's fault. Sending a random validator (one that didn't
come from the server) to a server is undefined.
Both behaviors are valid. As are others, such as returning an error.
Or doing something different every time.
The only thing that IS defined for a client is for it to return a
validator (from an e-tag) obtained from a given server to the same
server as a match condition.
Keep your wombat in Australia...or don't be surprised if it bites you.
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-05
Date: Sun, 5 Mar 2023 08:15:32 -0500
On 04-Mar-23 23:24, Paul Gilmartin via curl-users wrote:
> On 3/4/23 15:41:44, Timothe Litt via curl-users wrote:
>
>> ...
>> Section 6 also discusses precedence and evaluation order.
>>
>> As I said, read the whole RFC.
>>
>> Your test isn't valid. An E-Tag validator is only meaningful to the
>> server that sent it.
>> ...
>> For example, consider a validator that internally looks like
>> <mtime>-<size>-<expires>. If the server doesn't keep a side database
>> of validators, it might try to parse it, and since "wombat" isn't in
>> that format, give up.
>
> I'm calling it the site. Another URL on a different site let ETag
> dominate
> and didn't give up on "wombat", not calling it a matcn.
>
It's not the site's fault. Sending a random validator (one that didn't
come from the server) to a server is undefined.
Both behaviors are valid. As are others, such as returning an error.
Or doing something different every time.
The only thing that IS defined for a client is for it to return a
validator (from an e-tag) obtained from a given server to the same
server as a match condition.
Keep your wombat in Australia...or don't be surprised if it bites you.
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