In the following code the argument numItems is ignored. In contrast, in the function writeCallback immediately following, it is multiplied by size.

Fix: replace line 839 with

return req->options.bodyReader(buffer, size * numItems, req->options.bodyReaderData);

A URL like

http://localhost/maps/torridon.ctm1?type=metadata

does not work properly because the extra info '?type=metadata' is stripped from the URL in the Windows implementation of the Naett library.

The fix is to change this line:

to

req->resource = wcsndup(components.lpszUrlPath, components.dwUrlPathLength + components.dwExtraInfoLength);

I found copious memory leaks when using Naett in Windows. I was freeing up memory using naettFree for the naettReq object, and naettClose for the naettRes object,

The memory leaks can be fixed by adding free(req->options.method); to naettFree so that it becomes:

void naettFree(naettReq* request) {
    assert(request != NULL);

    InternalRequest* req = (InternalRequest*)request;
    naettPlatformFreeRequest(req);
    KVLink* node = req->options.headers;
    freeKVList(node);
    free((void*)req->url);
    free(req->options.method);
    free(request);
}

and adding free(res->body.data); to naettClose so that it becomes:

void naettClose(naettRes* response) {
    assert(response != NULL);

    InternalResponse* res = (InternalResponse*)response;
    res->request = NULL;
    naettPlatformCloseResponse(res);
    KVLink* node = res->headers;
    freeKVList(node);
    free(res->body.data);
    free(response);
}

At least on Windows, naett seems to leak some strings set by stringSetter.

Report after running (it just leaks the user agent string):

C:\dev\ppsspp\ext\naett\naett.c(154) : {4247868} normal block at 0x0000021496CEE120, 31 bytes long.
 Data: <PPSSPP/v1.16.5-1> 50 50 53 53 50 50 2F 76 31 2E 31 36 2E 35 2D 31 
C:\dev\ppsspp\ext\naett\naett.c(154) : {4243564} normal block at 0x0000021496CE9E00, 31 bytes long.
 Data: <PPSSPP/v1.16.5-1> 50 50 53 53 50 50 2F 76 31 2E 31 36 2E 35 2D 31 
C:\dev\ppsspp\ext\naett\naett.c(154) : {4241788} normal block at 0x0000021496CEE1E0, 31 bytes long.
 Data: <PPSSPP/v1.16.5-1> 50 50 53 53 50 50 2F 76 31 2E 31 36 2E 35 2D 31 
C:\dev\ppsspp\ext\naett\naett.c(154) : {4067325} normal block at 0x0000021496CE8D80, 31 bytes long.
 Data: <PPSSPP/v1.16.5-1> 50 50 53 53 50 50 2F 76 31 2E 31 36 2E 35 2D 31 

naett.c(154) is simply char* stringCopy = strdup(param->string);.

The Java byte array 'buffer' is created here:

The function NewByteArray creates a local reference which is not deleted. The fix is to add this line after the 'finally' label, at line 1592 of naett.c:

(*env)->DeleteLocalRef(env,buffer);

I'm already using a JNI_OnLoad in my app, so since naett defines one, I get a multiple definition error.

So what's needed is some way to pass your jni environment into naett, instead of having it try to grab it itself. Scratch that, I see that naettPlatformInit can already do it. So I only need to get rid of the extra JNI_OnLoad somehow.

Can we have a define maybe? #ifdef USE_EXISTING_JNI_ONLOAD for example.

For some reason the function wsprintfW cannot be found and causes a link error when using the Naett library for a Windows Qt app. The function is used here:

and of course in the amalgamation. The fix is to use the standard function swprintf and change the line of code to:

 swprintf(contentLengthHeader, 64, L"Content-Length: %d", contentLength);

This statement (as far as I understand the JNI) creates a local reference:

but it is not deleted, like the other local references, here:

The fix is to add the following statement at line 1501:

(*env)->DeleteLocalRef(env, values);

Compilation in Visual Studio 2022 gives this warning:

warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _strdup.

The warning can be removed by adding the line

#define strdup _strdup

to this section of code:

I don't have access to my git version as a preprocessor variable that I can pass into naett in the build, but I do have it as a const char *. So I'd like to set a useragent based on it at runtime, either as a parameter for naettInit, or simply as a naettOption for each request (or ability to leave it out altogether so you can just set it with naettHeader).

I'm happy to do a PR, though it would probably be quicker for you to do it.

plz add cookie support. enable, get and set cookie feature... like java cookieHandler and cookieManager.

The variable header is passed to DeleteLocalRef here:

and in the amalgamation:

The statement is incorrect, because header is of an invalid type

I believe that it did not trigger an exception because header is always null when the incorrect statement is executed; but nevertheless it should be deleted.

It would be nice to check the progress of larger downloads.

Something like this:

	if (!naettComplete(res_)) {
		// Update progress
		int downloadedBytes = 0, totalBytes= 0;
		naettGetProgress(res_, &downloadedBytes , &totalBytes);
                // ...
	}

If the size is unknown, *totalSize would be set to -1.

I guess cleanest would be if naettComplete also had two output parameters, downloadedBytes and totalBytes.

Actually I guess this can be hacked by manually reading the Content-Length header, and then checking res->body.size.

Though it occurs to me that there's a data race - if I read headers while !completed, it may be that the headers are currently being filled in.

Here's my current hack that 'works' (doing the below if naettComplete() didn't return true) but has at least two races:

	const char *header = naettGetHeader(res_, "Content-Length");
	if (header) {
		strlcpy(buf, sizeof(buf), header);
		sscanf(buf, "%d", &total);
		int size;
		naettGetBody(res_, &size);
		progress_.Update(size, total);
	}

In the iOS, Linux and Android implementations the parameter timeoutMS in the RequestOptions structure is used to set the timeout. This parameter is ignored in the Windows implementation, causing different behaviour.