Buy commercial curl support. 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 Daniel himself.
Re: %{filename_effective but not transmit file?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-users <curl-users_at_lists.haxx.se>
Date: Wed, 11 Sep 2024 18:09:54 -0700
On Wed, Sep 11, 2024 at 05:47:50PM -0600, Paul Gilmartin via curl-users wrote:
> Is it possible to get %{filename_effective without transmitting
> the file? I'm trying to make the ETag name pend on that,
> something like:
> "--etag-compare %{filename_effectiv.etag"
>
> So far, the best I can do is perform a trial fetch, directing
> the output to a read-only directory, failing but returning
> %{filename_ effective and using that in the real fetch.
Adding --head should basically do that in a clean way.
> is there a server-side TOCTTOU timing hazard? I'm imagining
I imagine there could be one. It's theoretically possible for the domain name
to expire, be snapped up by scammers and start serving malware between the
initial check and final download. Worst case.
> a busy server which:
> o declines to send a resource because of ETag match
> o Updates the resource concurrently
> o returns the ETag matching the new version.
I don't think you can ever completely rely on ETag matching. The ETag of a
resource can change even if the resource hasn't, although the reverse isn't
supposed to also be true. I would consider a server to be broken that uses two
different ETags while handling a single request, but I haven't looked at the
specs to see if it's technically allowed.
Dan
Date: Wed, 11 Sep 2024 18:09:54 -0700
On Wed, Sep 11, 2024 at 05:47:50PM -0600, Paul Gilmartin via curl-users wrote:
> Is it possible to get %{filename_effective without transmitting
> the file? I'm trying to make the ETag name pend on that,
> something like:
> "--etag-compare %{filename_effectiv.etag"
>
> So far, the best I can do is perform a trial fetch, directing
> the output to a read-only directory, failing but returning
> %{filename_ effective and using that in the real fetch.
Adding --head should basically do that in a clean way.
> is there a server-side TOCTTOU timing hazard? I'm imagining
I imagine there could be one. It's theoretically possible for the domain name
to expire, be snapped up by scammers and start serving malware between the
initial check and final download. Worst case.
> a busy server which:
> o declines to send a resource because of ETag match
> o Updates the resource concurrently
> o returns the ETag matching the new version.
I don't think you can ever completely rely on ETag matching. The ETag of a
resource can change even if the resource hasn't, although the reverse isn't
supposed to also be true. I would consider a server to be broken that uses two
different ETags while handling a single request, but I haven't looked at the
specs to see if it's technically allowed.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-09-12