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: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 4 Jan 2023 10:22:57 +0100
> Am 04.01.2023 um 09:08 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> 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
>
> "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.
>
>> --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)
>
> 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.
In general, we should expect that most people who do "curl https://something" do not really care what version is in play. They want the resource and expect curl to use the best way it knows of to get it. So, eventually, that will attempt also HTTP/3 in the future, based on whatever it thinks makes it suitable for trying it.
And then there are the cases where someone really wants to nail it down. That is what we are talking here, I guess. Ultimately, what is given on the command line is converted by curl into TCP and/or QUIC and the ALPN list for the connection (ignoring the http: cases). For people who really want to control this, specifying the ALPN list on the command line seems the best option. Someone might want to check if a server is willing to negotiate "h3-29", for example.
Besides that, we are talking about usability, e.g. making it easy to specify a common ALPN list. Currently, we have implied ALPNs (**):
- "--http1.1" -> ALPN "http/1.1"
- "--http2" -> ALPN "h2,http/1.1"
- "--http3" -> ALPN "h3" (*experimental, changeable)
- none -> ALPN "h2,http/1.1" (used to be only "http/1.1" when h2 was experimental)
- future none -> ALPN "h3,h2,http/1.1" (once, h3 leaves experimental)
right?
**) by ALPN here I mean the semantics of it. An ALPN of "h3,h2" would be split for the 2 connections attempted.
One other nice thing about a ALPN list is that it is ordered by preference. So, ALPN="h3,h2" and ALPN="h2,h3" could trigger different behaviour. Once curl digests HTTPS DNS records, it needs to interpret ALPN entries from those anyway.
Alt-Svc is really a snake pit. I am not sure if we need command line options for that, apart from specifying a complete entry for interpretation.
tl;dr
We have "--proto list" and could extend that to understand the ALPN protocol identifiers.
>> 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.
>
> 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.
>
> --
>
> / 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/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Wed, 4 Jan 2023 10:22:57 +0100
> Am 04.01.2023 um 09:08 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> 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
>
> "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.
>
>> --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)
>
> 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.
In general, we should expect that most people who do "curl https://something" do not really care what version is in play. They want the resource and expect curl to use the best way it knows of to get it. So, eventually, that will attempt also HTTP/3 in the future, based on whatever it thinks makes it suitable for trying it.
And then there are the cases where someone really wants to nail it down. That is what we are talking here, I guess. Ultimately, what is given on the command line is converted by curl into TCP and/or QUIC and the ALPN list for the connection (ignoring the http: cases). For people who really want to control this, specifying the ALPN list on the command line seems the best option. Someone might want to check if a server is willing to negotiate "h3-29", for example.
Besides that, we are talking about usability, e.g. making it easy to specify a common ALPN list. Currently, we have implied ALPNs (**):
- "--http1.1" -> ALPN "http/1.1"
- "--http2" -> ALPN "h2,http/1.1"
- "--http3" -> ALPN "h3" (*experimental, changeable)
- none -> ALPN "h2,http/1.1" (used to be only "http/1.1" when h2 was experimental)
- future none -> ALPN "h3,h2,http/1.1" (once, h3 leaves experimental)
right?
**) by ALPN here I mean the semantics of it. An ALPN of "h3,h2" would be split for the 2 connections attempted.
One other nice thing about a ALPN list is that it is ordered by preference. So, ALPN="h3,h2" and ALPN="h2,h3" could trigger different behaviour. Once curl digests HTTPS DNS records, it needs to interpret ALPN entries from those anyway.
Alt-Svc is really a snake pit. I am not sure if we need command line options for that, apart from specifying a complete entry for interpretation.
tl;dr
We have "--proto list" and could extend that to understand the ALPN protocol identifiers.
>> 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.
>
> 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.
>
> --
>
> / 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/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-04