Re: curl config file based on domain or inline variables based on request

--===============5722563311886975505==
Content-Type: multipart/alternative; boundary="000000000000c1a4300645aeca6d"

--000000000000c1a4300645aeca6d
Content-Type: text/plain; charset="UTF-8"

Yeah. That's really similar and would help in my usecase as well.

I don't know what it currently does, as I am not experienced enough to read
(or even write) the source code (in that detail).

Would it be architectural a challenge to move URL/Domain parsing to the
beginning of the command parsing?

For example in JS I'd probably do an
(Heavily abstracted, ofc that flow is way more complex)

function handleURL(url, args) {
  const parsedURL= new URL(url)
  // Parsing url first
  const config = await Bun.file(".curlrc").then(file => {
    return parseConfig({
      domain: parsedURL.hostname,
      configFileHandle: file
    })
  }
}

Or something.
Especially since the URL that is passed is not dynamic, except for the path
part when globbing is used.
Or can the domain part also be dynamic with globbing?

Other than that, the domain should be static from what I know and could be
parsed in the beginning of the internal flow.
The parsing of the URL is not dependent of the config itself, as no config
(or argument) setting allows for modifications of the passed URL, right?

At what point are the variables for write-out calculated? Maybe those could
partially be calculated earlier, if it doesn't fragment the code too much.

Which would also work with multiple urls.
And then providing the parsed url variables either as env vars or as
internal variable to the following parser.

On Thu, 11 Dec 2025, 13:04 Daniel Stenberg, <[email protected]> wrote:

> On Thu, 11 Dec 2025, Bastian Jesuiter via curl-users wrote:
>
> > The curlrc would include the a header with a {{ domain }} like variable
> > syntax.
> >
> > Like:
> > header @path/{{domain}}.txt
> >
> > Where the domain will be inferred by the given domain in the command.
>
> I like this idea! Let me also mention that we have a similar idea listed
> in
> the TODO:
>
>    https://curl.se/docs/todo.html#hostname-sections-in-config-files
>
> It would get roughly the same thing with a syntax like this:
>
> [domain]
>    header @path/special.txt
>
> I think both takes could be worth exploring. They have roughly the same
> challenge: they make it necessary to parse the config file (again?) after
> each
> URL has been retrieved, so that it knows the domain.
>
> --
>
>   / daniel.haxx.se || https://rock-solid.curl.dev
>

--000000000000c1a4300645aeca6d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Yeah. That&#39;s really similar and would help in my usec=
ase as well.=C2=A0<div dir=3D"auto"><br></div><div dir=3D"auto">I don&#39;t=
 know what it currently does, as I am not experienced enough to read (or ev=
en write) the source code (in that detail).=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Would it be architectural a challenge to move URL=
/Domain parsing to the beginning of the command parsing?</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">For example in JS I&#39;d probably do an=
=C2=A0</div><div dir=3D"auto">(Heavily abstracted, ofc that flow is way mor=
e complex)</div><div dir=3D"auto"><br></div><div dir=3D"auto">function hand=
leURL(url, args) {</div><div dir=3D"auto">=C2=A0 const parsedURL=3D new URL=
(url)=C2=A0</div><div dir=3D"auto">=C2=A0 // Parsing url first</div><div di=
r=3D"auto">=C2=A0 const config =3D await Bun.file(&quot;.curlrc&quot;).then=
(file =3D&gt; {</div><div dir=3D"auto">=C2=A0 =C2=A0 return parseConfig({</=
div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 domain: parsedURL.hostname,</div=
><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 configFileHandle: file</div><div di=
r=3D"auto">=C2=A0 =C2=A0 })</div><div dir=3D"auto">=C2=A0 }</div><div dir=
=3D"auto">}</div><div dir=3D"auto"><br></div><div dir=3D"auto">Or something=
.=C2=A0</div><div dir=3D"auto">Especially since the URL that is passed is n=
ot dynamic, except for the path part when globbing is used.=C2=A0</div><div=
 dir=3D"auto">Or can the domain part also be dynamic with globbing?=C2=A0</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Other than that, the doma=
in should be static from what I know and could be parsed in the beginning o=
f the internal flow.=C2=A0</div><div dir=3D"auto">The parsing of the URL is=
 not dependent of the config itself, as no config (or argument) setting all=
ows for modifications of the passed URL, right?=C2=A0</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">At what point are the variables for write-out=
 calculated? Maybe those could partially be calculated earlier, if it doesn=
&#39;t fragment the code too much.=C2=A0</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Which would also work with multiple urls.</div><div dir=3D=
"auto">And then providing the parsed url variables either as env vars or as=
 internal variable to the following parser.=C2=A0</div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, 11 Dec 2025, 13:04 Daniel Stenberg, &lt;<a href=3D"mailto:daniel@=
haxx.se">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Thu, 11 Dec 2025, Bastian Jesuiter via curl-users wrote:<br>
<br>
&gt; The curlrc would include the a header with a {{ domain }} like variabl=
e<br>
&gt; syntax.<br>
&gt;<br>
&gt; Like:<br>
&gt; header @path/{{domain}}.txt<br>
&gt;<br>
&gt; Where the domain will be inferred by the given domain in the command.<=
br>
<br>
I like this idea! Let me also mention that we have a similar idea listed in=
 <br>
the TODO:<br>
<br>
=C2=A0 =C2=A0<a href=3D"https://curl.se/docs/todo.html#hostname-sections-in=
-config-files" rel=3D"noreferrer noreferrer" target=3D"_blank">https://curl=
.se/docs/todo.html#hostname-sections-in-config-files</a><br>
<br>
It would get roughly the same thing with a syntax like this:<br>
<br>
[domain]<br>
=C2=A0 =C2=A0header @path/special.txt<br>
<br>
I think both takes could be worth exploring. They have roughly the same <br=
>
challenge: they make it necessary to parse the config file (again?) after e=
ach <br>
URL has been retrieved, so that it knows the domain.<br>
<br>
-- <br>
<br>
=C2=A0 / <a href=3D"http://daniel.haxx.se" rel=3D"noreferrer noreferrer" ta=
rget=3D"_blank">daniel.haxx.se</a> || <a href=3D"https://rock-solid.curl.de=
v" rel=3D"noreferrer noreferrer" target=3D"_blank">https://rock-solid.curl.=
dev</a><br>
</blockquote></div>

--000000000000c1a4300645aeca6d--

--===============5722563311886975505==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html

--===============5722563311886975505==--