Skip to content

libcurl from a Windows dll sometimes incorrectly identifies presence of ALPN #7742

Closed
@wyattoday

Description

@wyattoday

I did this

Compile latest libcurl on Windows with SChannel (either static or dynamic library). Then include either static or dynamic libcurl from inside a dll that will be run in another host application. ALPN detection will now sometimes fail depending on whether the host application was compiled with the correctly configured Application Manifest file.

In this scenario we control the dll (which eventually calls libCurl functionality). However, we do not control the "host application". Meaning the functionality we call in curl could work fine or break depending on whether the host application was compiled and packaged correctly.

Also, this is not a hypothetical situation -- we've seen this in the field.

I expected the following

libCurl should work the same regardless of whether the host application has a manifest configured correctly.

curl/libcurl version

7.79.0

operating system

Windows 8.1 or newer.

Why does it fail?

Incorrect Windows Version detection is used. Or, rather, flaky version detection is used. This was a problem of Microsoft's making (they decided to make some version detection functions flaky).

Solution

Use alternative version detection functions that always returns the correct version. I've already tested and made a PR with the solution. See #7727

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions