createInputStream not working on Windows (10)

Trying to get json data from a https url. This works fine on MacOS but returns 0 immediately on Windows 10. I have tried with two different Windows machines.

static juce::String get_url(const juce::URL& url) {
    Utils::log_info(juce::String("Fetching url: ") + url.toString(false));

    juce::StringPairArray responseHeaders;
    int statusCode = 0;
    auto stream = std::unique_ptr<juce::InputStream>(
        url.createInputStream(false, nullptr, nullptr, "application/json", 5000, &responseHeaders, &statusCode));
    if (stream && statusCode == 200) {
        auto result = stream->readEntireStreamAsString();
        return result;

Switching to the cpr library that uses libcurl everything works as expected

cpr::Response r = cpr::Get(cpr::Url(url.toString(false).toStdString()));
if (r.status_code == 200) {
    return r.text;

What could be the issue with the JUCE version and how to fix it?

cookies? may be similar to this discussion: URL::readEntireTextStream() inconsitent across platforms

Because statusCode=0 before the call, it not clear if the createInputStream() sets it to 0 or if it just does not update it, which will seem to contradict the doc on statusCode:

EDIT: Do you have an Antivirus software running on Windows? Do you see any relevant exception in the console output if you can use one ?

In juce_win32_Network.cpp, the connect function fails: isError() below returns true and the createInputStream returns a nullptr in the end. I stepped through the createConnection but did not see any immediate reason for the failure…

bool connect (WebInputStream::Listener* listener)
            const ScopedLock lock (createConnectionLock);

            if (hasBeenCancelled)
                return false;

        String address = url.toString (! isPost);

        while (numRedirectsToFollow-- >= 0)
            createConnection (address, listener);

            if (! isError())

Ah, ok. If I remove the “application/json” header parameter, then it works :man_shrugging:

Specifying the content type header works on MacOS and I know the media type is definitely correct… I guess this is just some Windows thing again :slightly_frowning_face:

Maybe an option to use libcurl on Windows as well would improve this.

Shouldn’t the header value be “Content-Type: application/json” instead of just “application/json”?

1 Like