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: HTTP/3 options
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Thu, 5 Jan 2023 08:11:43 -0500
On 04-Jan-23 03:08, Daniel Stenberg wrote:
> On Tue, 3 Jan 2023, Timothe Litt via curl-library wrote:
>
> Thanks, this is certainly an interesting idea.
>
>> --http=3 - use http3, fall back to 2, 1.1, 1.0, 0.9, ...
>
> We don't use '='-separators in our option parser so unless we
> introduce it now, it would rather be
>
> --http 3
>
The gnu parsers that accept = also take the argument as the following
word. I rather prefer '=', but that's a nit.
Whatever works - the point was to simplify, exact syntax is up to you.
> "0.9" is never a version used in (curl) requests, it is prehistoric
> *response*. I don't think should mix 0.9-acceptance into this option.
>
OK. The man page has --http0.9. I was just looking for all the things
that could be subsumed. Missed that it's a response.
It's unfortunate that all the other --http* options control the request,
but this one controls the acceptable response.
Probably too late to fix now, but in any case for another day.
>> --http=3. use http3 or die
>>
>> --http=(3,1.1) - try http3, fall back to 1.1, 1.0...
>>
>> --http=(3,1.1.) - try http3, 1.1 or die
>>
>> --http=2. = Use http2 or die (roughly --http2 --http-prior-knowledge)
>
> Maybe the period is a too subtle as a "stop" as it is also used in "1.1".
>
> How about a slight tweak of the syntax:
>
> "3-" means version 3 or anything else that curl thinks is fine
>
> "3" means only version 3
>
> "3-2" means version 2 or fallback to 2 (excluding 1.1)
>
> "3-1.1" means version 3 or fallback to 2 or 1.1
>
> "3,1.1" means version or fallback to 1.1
>
> "1.0" means please use 1.0 (only)
>
That works too. I don't think '.' ambiguous, since if it means stop,
it's at the end of the string. I'm not wedded to any particular detail;
the important idea was to reduce the proliferation of --http* options
and instead let the user declare his priorities simply.
> Details:
>
> It cannot ever fallback to 1.0, so having "3-1.0" will not make curl
> actually try 1.0 in the request.
>
> Using "0.9" in the string would be invalid, it is never used in
> requests.
>
> We could accept version "1" as a shortcut for "1.1".
>
> This leaves room for expanding to a future version 4.
What's the limit? If we live long enough, http v642 should fit the
syntax :-( --http 642-491,1.1
>
>> alt-svc really should be internal to CURL - e.g. in
>> ~/.curl-altsvc.cache or some such.
>
> Maybe. That would introduce challenges when you run a bazillion
> different concurrent curls, potentially with lots of different use
> cases and testing and
> torturing internal and external sites.
>
I don' t think that's the typical (or common) user case. I'm OK with
allowing an advanced user to specify the cache file(s) to use - or
--no-alt-svc. I just don't think that the regular user should have to
do anything to enable this background optimization.
There's a difference between torture tests and "just get me this file,
best way you know how".
I think the command line tool should do the latter by default.
Supporting the advanced user with the command line and the application
using the library can work harder for exotic cases.
I mentioned it because it interacts with the other --http* options, and
it's another case where curl makes the user add options and keep track
of auxiliary files instead of using capabilities.
As a principle, I'd rather have curl try the most efficient
protocols/options, and if it fails, let the user say '--no-something'
than have the user say 'use this' 'use that' 'use something else'.
> Also, alt-svc as a technology does not seem to have a very bright
> future so I'm not convinced it is worth us spending a lot of efforts
> on fine tuning how to use this. The future rather looks like an
> updated header and use of the HTTPS record.
>
Fair enough. I'm not tracking its evolution.
I'm not focused on each individual feature. Rather, on having (at
least) the command line tool default to autodetecting and using the
"best" features, rather than just adding more options.
I guess one metric might be the length of the option string required to
express intent and make a transfer happen. Shorter is better.
Received on 2023-01-05
Date: Thu, 5 Jan 2023 08:11:43 -0500
On 04-Jan-23 03:08, Daniel Stenberg wrote:
> On Tue, 3 Jan 2023, Timothe Litt via curl-library wrote:
>
> Thanks, this is certainly an interesting idea.
>
>> --http=3 - use http3, fall back to 2, 1.1, 1.0, 0.9, ...
>
> We don't use '='-separators in our option parser so unless we
> introduce it now, it would rather be
>
> --http 3
>
The gnu parsers that accept = also take the argument as the following
word. I rather prefer '=', but that's a nit.
Whatever works - the point was to simplify, exact syntax is up to you.
> "0.9" is never a version used in (curl) requests, it is prehistoric
> *response*. I don't think should mix 0.9-acceptance into this option.
>
OK. The man page has --http0.9. I was just looking for all the things
that could be subsumed. Missed that it's a response.
It's unfortunate that all the other --http* options control the request,
but this one controls the acceptable response.
Probably too late to fix now, but in any case for another day.
>> --http=3. use http3 or die
>>
>> --http=(3,1.1) - try http3, fall back to 1.1, 1.0...
>>
>> --http=(3,1.1.) - try http3, 1.1 or die
>>
>> --http=2. = Use http2 or die (roughly --http2 --http-prior-knowledge)
>
> Maybe the period is a too subtle as a "stop" as it is also used in "1.1".
>
> How about a slight tweak of the syntax:
>
> "3-" means version 3 or anything else that curl thinks is fine
>
> "3" means only version 3
>
> "3-2" means version 2 or fallback to 2 (excluding 1.1)
>
> "3-1.1" means version 3 or fallback to 2 or 1.1
>
> "3,1.1" means version or fallback to 1.1
>
> "1.0" means please use 1.0 (only)
>
That works too. I don't think '.' ambiguous, since if it means stop,
it's at the end of the string. I'm not wedded to any particular detail;
the important idea was to reduce the proliferation of --http* options
and instead let the user declare his priorities simply.
> Details:
>
> It cannot ever fallback to 1.0, so having "3-1.0" will not make curl
> actually try 1.0 in the request.
>
> Using "0.9" in the string would be invalid, it is never used in
> requests.
>
> We could accept version "1" as a shortcut for "1.1".
>
> This leaves room for expanding to a future version 4.
What's the limit? If we live long enough, http v642 should fit the
syntax :-( --http 642-491,1.1
>
>> alt-svc really should be internal to CURL - e.g. in
>> ~/.curl-altsvc.cache or some such.
>
> Maybe. That would introduce challenges when you run a bazillion
> different concurrent curls, potentially with lots of different use
> cases and testing and
> torturing internal and external sites.
>
I don' t think that's the typical (or common) user case. I'm OK with
allowing an advanced user to specify the cache file(s) to use - or
--no-alt-svc. I just don't think that the regular user should have to
do anything to enable this background optimization.
There's a difference between torture tests and "just get me this file,
best way you know how".
I think the command line tool should do the latter by default.
Supporting the advanced user with the command line and the application
using the library can work harder for exotic cases.
I mentioned it because it interacts with the other --http* options, and
it's another case where curl makes the user add options and keep track
of auxiliary files instead of using capabilities.
As a principle, I'd rather have curl try the most efficient
protocols/options, and if it fails, let the user say '--no-something'
than have the user say 'use this' 'use that' 'use something else'.
> Also, alt-svc as a technology does not seem to have a very bright
> future so I'm not convinced it is worth us spending a lot of efforts
> on fine tuning how to use this. The future rather looks like an
> updated header and use of the HTTPS record.
>
Fair enough. I'm not tracking its evolution.
I'm not focused on each individual feature. Rather, on having (at
least) the command line tool default to autodetecting and using the
"best" features, rather than just adding more options.
I guess one metric might be the length of the option string required to
express intent and make a transfer happen. Shorter is better.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature