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: are ALPN values desirable command line 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: Tue, 24 Oct 2023 09:00:13 +0200
> Am 24.10.2023 um 00:32 schrieb Stephen Farrell via curl-library <curl-library_at_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
Date: Tue, 24 Oct 2023 09:00:13 +0200
> Am 24.10.2023 um 00:32 schrieb Stephen Farrell via curl-library <curl-library_at_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.htmlReceived on 2023-10-24