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 11:04:23 +0100
> Am 04.01.2023 um 10:50 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> On Wed, 4 Jan 2023, Stefan Eissing wrote:
>
>> 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.
>
> I actually don't think we've had users ask for this level of fiddling in the past.
>
> If we would allow that, I imagine we need to provide a mapping as well. Like send APLN XXX and if agreed to, treat it as if it is YYYY. If not, curl itself would need to know that "h3-moonbase" is that new magic h3 attempt I work on in secret, possibly by making assumptions about how the id is created.
I think we need to deal with those values found in HTTPS records. If we want to expose that on the command line is another thing. agreed.
>
> Something like:
>
> --alpn-pref h3-29=h3
>
> I am however not convinced that we need to go that route unless a user actually steps forward and explains a use case for this.
>
>> 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?
>
> Yes, in practise that is what we are talking about. My thinking is however that the term alpn is too esoteric and unknown for users of the tool and therefore I rather expose and talk about this in the terms of "HTTP versions". A little simplified, but I think it can work.
Would
--proto h3,h2
--proto http3,http2
--proto http1-3
work here?
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
Date: Wed, 4 Jan 2023 11:04:23 +0100
> Am 04.01.2023 um 10:50 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> On Wed, 4 Jan 2023, Stefan Eissing wrote:
>
>> 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.
>
> I actually don't think we've had users ask for this level of fiddling in the past.
>
> If we would allow that, I imagine we need to provide a mapping as well. Like send APLN XXX and if agreed to, treat it as if it is YYYY. If not, curl itself would need to know that "h3-moonbase" is that new magic h3 attempt I work on in secret, possibly by making assumptions about how the id is created.
I think we need to deal with those values found in HTTPS records. If we want to expose that on the command line is another thing. agreed.
>
> Something like:
>
> --alpn-pref h3-29=h3
>
> I am however not convinced that we need to go that route unless a user actually steps forward and explains a use case for this.
>
>> 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?
>
> Yes, in practise that is what we are talking about. My thinking is however that the term alpn is too esoteric and unknown for users of the tool and therefore I rather expose and talk about this in the terms of "HTTP versions". A little simplified, but I think it can work.
Would
--proto h3,h2
--proto http3,http2
--proto http1-3
work here?
> --
>
> / 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.htmlReceived on 2023-01-04