%{filename_effective but not transmit file?
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.
is there a server-side TOCTTOU timing hazard? I'm imagining
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.
The server should not return an ETag in the headers
different from the one which caused it not to send
a resource.
--
Thanks,
gil
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette: https://curl.se/mail/etiquette.html
Re: %{filename_effective but not transmit file?
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.html
Re: %{filename_effective but not transmit file?
On 9/11/24 19:09, Dan Fandrich via curl-users wrote:
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.
.
Close, but not quite. what I really want is:
614 $ cat h
#! /bin/sh -x
curl --head \
--remote-name \
--remote-header-name \
--write-out '%{filename_effective}\n' \
'https://ibm-docs-static-content.s3.us.cloud-object-storage.appdomain.cloud/pdx/SSLTBW_3.1.0/zOS310-Refresh-Indexed-PDF-package-(2024-07-31).zip'
But it fails with:
615 $ sh h
curl: showing headers and --remote-header-name cannot be combined
curl: try 'curl --help' or 'curl --manual' for more information
616 $
--
Thanks,
gil
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette: https://curl.se/mail/etiquette.html
Re: %{filename_effective but not transmit file?
On Wed, 11 Sep 2024, Paul Gilmartin via curl-users wrote: curl: showing headers and --remote-header-name cannot be combined Since --head implies that the body is not saved, we can actually make this work fairly easy... -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
Re: %{filename_effective but not transmit file?
On Thu, 12 Sep 2024, Daniel Stenberg via curl-users wrote: Since --head implies that the body is not saved, we can actually make this work fairly easy... Eh, no. I was not thinking right. It still needs to save the headers in that final name that it will not know until several headers have already arrived. So not *that* simple. Basically what we need to do is to make the tool keep the initial set of headers in memory first before it has decided what file name to use, then save all the headers in the file name once it knows. That would fix this limitation. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
