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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 4 Jan 2023 10:50:19 +0100 (CET)
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.
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.
Date: Wed, 4 Jan 2023 10:50:19 +0100 (CET)
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.
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.
-- / 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