alank2

Thank you for the help rvk (and everyone in this thread!), instead of a loose end I now have a reason for why it is doing what it does. Going forward I'll ignore the status text always and just go with the result code. What made me nervous about this is that the status code itself is also retrieved from the same function as text and then later converted to an integer, so I'm not sure why this is an issue for status text, but not status code. Hopefully going forward it won't be.

I noticed this as well. I don't usually use the /install or /uninstall options but instead use Inno setup and sc.exe to stop/remove/install/start services. I usually (and I don't think it is the right way as Remy pointed out to me in another thread, I still need to do some testing on it to change) implement a ServiceExecute with a message loop that runs until the service is stopped, so something like this; while (!Terminated) //do not quit if process is running until it is finished { ServiceThread->ProcessRequests(true); Sleep(250); } If I add this to the above service, it doesn't add the OK from local execution of "project1 /install", but it does for some reason for "project1 /uninstall". How would you do this? Exactly. I know the local system account does change the environment that a service runs it as far as rights go, but I don't know what this would have a change in the WinHttpQueryHeaders().

Good thinking!!! This is it. When the service is configured to use "Local System Account" It does NOT report "OK". If I change it to administrators or my own user name, it does report "OK". Any ideas why local system account can't retrieve the status text even though it does properly retrieve the status code?

Yes. I'll give this a try.

Here is some test code that shows it. From the application (returns OK properly): From the service (does not return OK properly, but an empty string instead): result 200 '' The service saves to a file "c:\5\log.txt", but you can change where it saves it if you run the code. Build the service, admin cmd prompt, go win32\debug and run project1 /install, then run net start service1. it will create the c:\5\log.txt (or what you renamed it to) with the results of the GET to google. To uninstall just do net stop service1 followed by a project1 /uninstall. test.zip

My big concern isn't the status string, I can ignore it. My concern is that if that is not right, why, and what else might not be right.

Tested it on 10 and 11 same result.

I created a new 10.3.3 service application and put the code in - it does NOT return OK. The same code in a standalone application does return OK. I'll come up with a sample project I can post to see if others can reproduce the issue.

It is not consistent - I have another API that I use in the same service and it returns OK just fine, but if I do a GET @ https://google.com, it will not return OK. I then tried a new application (not service) with the same code (GET @ https://google.com), it works fine and returns OK. I rebuilt the project on 10.3.3, 11.3, and 12.2, and all of them return an empty string instead of OK. I wonder if it being a service has something to do with it. Next up I'll build a new service project service and see if the issue occurs with that.

This is a cut from the postman console which shows what the request returns (at least from postman): Content-Length: 126768 ----------------------------446648698401590502853205 Content-Disposition: form-data; name="select" Static Data ----------------------------446648698401590502853205 Content-Disposition: form-data; name="fileData"; filename="file.json" <file.json> ----------------------------446648698401590502853205 Content-Disposition: form-data; name="id" 1234567 ----------------------------446648698401590502853205-- HTTP/1.1 200 OK Date: Wed, 04 Dec 2024 18:55:06 GMT Content-Type: application/json; charset=utf-8

I think this was not real, but part of the LSize isn't the right value because of a debugger issue. Wouldn't it be encrypted if I captured it with wireshark (https)?

Unfortunately not.

I'm not making a lot of sense out of this windows function. Why would it return a size that doesn't include the terminating null \x00 character? When it returns the buffer, does it not null terminate the string? I'm not sure this is the issue as I modified the LSize to be 200 and let it make the second call and it still returned an empty string. edit: I'm back to why would WinHttpQueryHeaders return a proper 200 string that gets turned into an integer just fine, but not the OK part. Is there any way to access the actual response as bytes to see if it matches my postman test?

The original call to WinHttpQueryHeaders has a LSize==0, and it returns with ERROR_INSUFFICIENT_BUFFER. They intentionally call with a 0 to get the size. It skips by "if GetLastError <> ERROR_INSUFFICIENT_BUFFER then" and moves to SetLength, but now my LSize is 16579768, so clearly the debugger is back to not working right again. Moving to the CPU I can see that is loads EDX with a value 2 which is the size of OK. Then it does a SHR edx,1 and changes the value from 2 to 1. Then a DEC edx which changes it from 1 to 0. So the mystery here is WHY this line: SetLength(Result, LSize div SizeOf(Char) - 1); is dividing by sizeof(Char) which is apparently 2 and then subtracting 1. edit: looking at WinHttpQueryHeaders , it shows: [in, out] lpdwBufferLength Pointer to a value of type DWORD that specifies the length of the data buffer, in bytes Since it is dealing with wide strings, 2 could be a zero terminator for the wide string and it thinks there is nothing to return. Why would this function not see the "OK" in the http response?

It is 32 bit. Removing the two .pas modules and turning on debug dcu's fixes the issue with inspecting LSize. It gets cleared properly now and returning from WinHttpQueryHeaders leaves LSize at 0 which is why it isn't allocating it or retrieving it. The status line in the raw is: HTTP/1.1 200 OK If it makes any difference, I am sending multipart/form-data.