Question

I don’t have very much information to work with here, yet. Our app sends an HTTP query to our server, and in all the cases we’ve used until now it has worked fine. But for one client, whose network goes through a proxy, their logs indicate that the request goes out successfully, but no reply ever returns, and our web server shows nothing in the logs about having received anything (at the time periods where the failures occurred, all that’s present in the logs is the downloading of a ZIP from inside the installer, as I mention next). This happens consistently for anyone on their network.

One strange thing is that the installer for the app sends an HTTP request for a ZIP file, and it completes just fine, but on launching the app, its first request (to a PHP file) fails. They share the same basic code that’s used for making the request, but just send different parameters. I have been trying to figure out what is really different about the two calls, and it basically boils down to:

• One is requesting a zip file, the other is sending parameters to a php file; file type filtering?
• The one that is failing has a handful of extra header parameters added. I’d understand if they got stripped by a proxy, but could it drop the request entirely if it had custom/unsupported headers?

Here’s a basic skeleton structure of the function calls:

    HINTERNET hInternetOpen = InternetOpen( szAppName, INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0 );
    HINTERNET hInternetConnect = InternetConnect( hInternetOpen, "www.server.com", INTERNET_DEFAULT_HTTP_PORT, NULL, NULL, INTERNET_SERVICE_HTTP, NULL, 0 );
    HINTERNET hRequest = HttpOpenRequest( hInternetConnect, "GET", "path/query.php?params=etc", NULL, NULL, "*/*", INTERNET_FLAG_RELOAD, 0 );
    // Here I was including some custom headers, such that szHeaders would look something like:
    // "KEY:12345\nTZ:New_York\n"
    HttpSendRequest( hRequest, szHeaders, dwHeadersLen, NULL, 0 );
    InternetReadFile( hRequest, lpBuf, dwBufSize, &dwAmtRead );

I will be setting up a new build that will provide much more error checking to figure out what part of the request failed and what error codes are returned. It also will do away with the custom headers, and any other inconsistencies between this and the installer.

I don’t really have a lot of faith that that stuff really is the cause, so in the meantime, I am looking for conjectures about what might be going wrong, or what things I should double-check or look out for. I was originally convinced it was simply a filtering issue with their locked-down network, but from talking with their IT group, the requests it’s making are not being blocked by them. Perhaps there are some non-standard things I am doing.

Answer 1

I’d recommend using tcpdump or wireshark to monitor the actual traffic going in and out of your web server. Do you see their request coming through at all? If not, I’d ask them to try the same thing, both inside and outside of the firewall, to see what’s happening there.