Web Deploy: Majority of installations fail (Source file not found)

[linder]

Okay, just for fun I switched my ISP. Please see IP 37.80.148.220 in your LOG. This time it is a LTE cellular powered network. No timeout or file not found issue.

Unfortunately, there is absolutely nothing we can do to investigate what is goint on on your server and why your server does not respond to the GET file request (but always work fine for you and me; and I am at least 5000 miles away). See attached screenshot. 7 successful web installs from your server. Not a single web install failed from here using your original web install stub.

Friedrich

[linder]

The download process is very simple. The HTTP component sends a "GET" file request to your server. But your server does not respond to this file request (when you see a "source file not found" error). There is absolutely nothing from the SetupBuilder side-of-view that can be done to work around it.

To make it even worse (for us) is that it ALWAYS works when we install from your server (5000+ miles away). So what options do we have to solve this?

Friedrich

[instrumentally]

If there was any issue in Web Install, we would see a lot of similar problem reports here and in our ticket system

Yes, I understand. But that observation isn't solving the problem at hand.

Have you looked at the LOG files? Would you agree that your initial "error 404" suspicion isn't what we are dealing with here?

[linder]

Have you looked at the LOG files? Would you agree that your initial "error 404" suspicion isn't what we are dealing with here?

Yes and no. Your server simply stops responding and the GET request does not even "get through". That's why you do not see the "404" in your LOG. So there is absolutely nothing the HTTP component (WinSock) can do because your server stops communicating. Do you see what I mean? Your server does not log or send the "404" (I agree with you on this). But how to continue with the download if your server does not response to the GET request?

Friedrich

[linder]

It would be interesting to see, what your LOG reports if a file cannot be downloaded because it is an unknown MIME type.

Would it be possible for you to check this? Create a simple empty SetupBuilder project and use the "Download File..." script action to download a file with an unknown MIME type (so it gets blocked). Do you see such a download request in your LOG? What does "Download File..." stores in %_SB_ERRORCODE% after such an unsuccessful action?

I know it does not help at all to solve your problem, but I am 100% sure it is not caused by SetupBuilder (otherwise we would have seen thousands of support requests since the last recompile of the HTTP component in May 2014).

Friedrich

[linder]

Yes, I understand. But that observation isn't solving the problem at hand.

Have you seen these LOG files? Would you agree that your initial "error 404" suspicion isn't what we are dealing with here?

BTW, please check the attached log entries. Both Web Installations stopped at file 00005.bin. But one Web Install is dated 3-22 and the other one two days later 3-24. And directly after the "download issue" we see /wp-login.php requests with "404" results. Can you shed some light on this?

Friedrich

[linder]

Or this one (see attached). The same IP started four Web Installations. And three minutes later again four Web Installations. And then again a few seconds later /wp-login.php request (404 result).

Any idea?

Friedrich

[linder]

And again (see attached screenshot). Four simultaneous web installs started. And of course, again a /wp-login.php (404).

What is this?

Friedrich

[linder]

And here again... Wouldn't you agree it's no accident that we see the same entries again and again with the /wp_login.php after the "failed" web install?

Friedrich

[linder]

And here... nearly identical IP addresses, but they are not the same. Downloading a similar set of Web Install cluster files. Then stops downloading and again /wp-login.php (404).

Are these "fake" Web Installs installs? Perhaps the Web Installs were stopped by the client and not the server?

Friedrich