Re: HTTP/3 options

[Timothe Litt via curl-library]

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, ...

  --http 3

We don't use '='-separators in our option parser so unless we introduce it now, it would rather be

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.

Probably too late to fix now, but in any case for another day.

It's unfortunate that all the other --http* options control the request, but this one controls the acceptable response.

--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.



 We could accept version "1" as a shortcut for "1.1".

 This leaves room for expanding to a future version 4.

 Using "0.9" in the string would be invalid, it is never used in requests.

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.

torturing internal and external sites.

Maybe. That would introduce challenges when you run a bazillion different concurrent curls, potentially with lots of different use cases and testing and

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.

OpenPGP_signature
Description: OpenPGP digital signature

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