Re: are ALPN values desirable command line options?

[Stefan Eissing via curl-library]

> Am 24.10.2023 um 00:32 schrieb Stephen Farrell via curl-library 
> <curl-library@lists.haxx.se>:
> 
> 
> Hiya,
> 
> On 23/10/2023 07:51, Daniel Stenberg wrote:
>> Are there actually cases where sending in a custom ALPN is likely to
>> be the right thing for a user to get a transfer going? I have not
>> heard of any such cases before.
> 
> On 23/10/2023 08:44, Stefan Eissing wrote:
>> For this to work, curl needs to know the ALPN protocol. Because otherwise, 
>> it does not know how to talk to the server or understand
>> the answer. If one would specify "--alpn xyz" what should curl do
>> when "xyz" as negotiated?
> I'm sensing skepticism:-) But that's fine. I don't actually know if

Well, "skepticism" insofar as I fail to imagine how it should work. ;) Maybe 
you could describe what curl should do in such a case?

> there are many sites that really need an ALPN ID that's not tied to
> the HTTP version. I looked at the registry [1] and not many IDs seem
> to me to be both relevant to curl and where there's likely a benefit
> for the client in sending - maybe "acme-tls/1" but not sure.
> 
> I do agree that the niche use-case I mentioned in the original mail
> wouldn't really justify adding such an option all by itself.
> 
> That said, I'll ask a few people at the IETF meeting in a couple of
> weeks and see if there's more to it than that.
> 
> If not, it's fine that this topic also fades away like the other
> from today (have to say, I liked Mark's phrasing of that one:-)
> 
> Cheers,
> S.
> 
> [1] 
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
> <OpenPGP_0xE4D8E9F997A833DD.asc>-- 
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html

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