Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#1497 No error message on failed download

Mike Hudson

I apologize if this is a duplicate bug.

I spent over 20 minutes wondering why I couldn't use MinGW. Finally it dawned on me.

The download of the files with mingw-get failed because I am behind a corporate firewall/proxy that requires authentication. EVERYTHING that wants to connect to the internet needs to authenticate to the proxy. All the browsers pop up an authentication window so I can put in my creds.

The problem is that the mingw-get window's messages flew by so fast that I couldn't see what was said. Then, the shell window just went away and I couldn't scroll up to see the errors.

I was able to connect to a different network to download the proper file, but it would have been nice to know that I needed to 20 minutes ago.


1 2 > >> (Page 1 of 2)
  • Keith Marshall
    Keith Marshall

    • milestone: --> Known_Feature
    • priority: 5 --> 3
    • assigned_to: nobody --> keithmarshall
  • Keith Marshall
    Keith Marshall

    Thank you for the report; I am aware of some download issues, but a formal bug report does no harm.

    You actually raise three separate, (although somewhat related issues):--

    1) If downloads are blocked by a firewall, then presumably that's because the firewall has been configured to block the host domain; it's doing its intended job, and we can do nothing to work around it. (I don't think this is the problem, in your case).

    2) Currently, mingw-get supports only one mechanism for authenticating to a proxy -- the Windows standard method where the credentials for each user are preconfigured, (e.g. by Internet Explorer setup), and recorded in the registry. That method works absolutely fine for me, behind the authenticating Squid proxy in my place of work; apparently it doesn't work for you, so you must be faced by a more draconian proxy configuration than I am. Ultimately, I would like to be able to support users with more difficult proxy configurations, but since I cannot reproduce your problem myself, I may need some assistance with specifying, coding and testing the alternatives. In the present alpha phase of development, this isn't a high priority for me, but I will willingly consider patches.

    3) mingw-get's diagnostics, particularly those related to download issues, could be improved; in some respects, there is too much informational noise, while some more serious issues may not be adequately reported. This is on my to-do list, but again, it isn't my highest priority at present.

  • Mike Hudson
    Mike Hudson

    Thanks for your response Keith.

    A little background on my proxy. The method used in the installer might have worked with the old way the proxy works, but not the new way.

    Old way: The domain and realm were always the same. One login would authenticate to everything.

    New way: The domain isn't always, the same, but the realm has some uniformity. I keep having to authenticate on pages that I've already received, like when flash ads or flash vids come up and request content from other sites. I'm not 100% sure why this is, but it's pretty annoying.

    I don't normally use IE but I have saved my proxy creds so I don't have to fill them in every time in IE.

    I'd be willing to test things and give you log files if/when you get around to this.

  • Scott Michel
    Scott Michel

    I've enclosed a patch that deals with authenticating proxies. I, like the original reporter, live behind an authenticating corporate firewall.

    Frankly, I'm not sure that this patch is stylistically where mingw-get would want to perform proxy authentication (i.e., getting InternetErrorDlg to pop up the window and prompt for credentials), but for an initial working patch, it does the job.

    Also, it's helpful to flush stderr in dmh->notify() because stderr is not line buffered, at least under mintty.

  • Scott Michel
    Scott Michel

    The patch (there has to be a place to upload this...)

    diff -r -U3 -x '*~' -x '*.o' -x '*.d' mingw-get-0.1-original/src/dmh.cpp mingw-get-0.1/src/dmh.cpp
    --- mingw-get-0.1-original/src/dmh.cpp 2010-10-05 00:13:27 -0700
    +++ mingw-get-0.1/src/dmh.cpp 2011-01-14 11:28:35 -0800
    @@ -201,7 +201,9 @@
    /* Display arbitrary text messages via the diagnostic message handler;
    * for the TTY subsystem, this is equivalent to printf() on stderr.
    - return vfprintf( stderr, fmt, argv );
    + int retval = vfprintf( stderr, fmt, argv );
    + fflush( stderr );
    + return retval;

    EXTERN_C uint16_t dmh_control( const uint16_t request, const uint16_t mask )
    diff -r -U3 -x '*~' -x '*.o' -x '*.d' mingw-get-0.1-original/src/pkginet.cpp mingw-get-0.1/src/pkginet.cpp
    --- mingw-get-0.1-original/src/pkginet.cpp 2010-03-30 13:29:26 -0700
    +++ mingw-get-0.1/src/pkginet.cpp 2011-01-14 12:34:03 -0800
    @@ -25,11 +25,14 @@
    #define WIN32_LEAN_AND_MEAN
    +/* Make GetConsoleWindow visible */
    +#define _WIN32_WINNT 0x0500

    #include <unistd.h>
    #include <stdlib.h>
    #include <string.h>
    #include <wininet.h>
    +#include <wincon.h>
    #include <errno.h>

    #include "dmh.h"
    @@ -86,7 +89,40 @@
    NULL, NULL, 0
    - return InternetOpenUrl( SessionHandle, URL, NULL, 0, 0, 0 );
    + /*
    + * Some care must be taken here to account for authenticating proxies. Using an existing
    + * connection to a HTTP server gets around the need to repeatedly authenticate.
    + */
    + HINTERNET urlHandle = InternetOpenUrl( SessionHandle, URL, NULL, 0, urlFlags, 0 );
    + if ( urlHandle != NULL ) {
    + DWORD lastError = GetLastError();
    + DWORD status = QueryStatus( urlHandle );
    + if ( status == HTTP_STATUS_PROXY_AUTH_REQ ) {
    + BOOL exitLoop = FALSE;
    + while ( exitLoop == FALSE ) {
    + DWORD dwError = InternetErrorDlg(GetConsoleWindow(), urlHandle, lastError,
    + NULL);
    + if ( dwError == ERROR_INTERNET_FORCE_RETRY ) {
    + BOOL httpReq = HttpSendRequest( urlHandle, NULL, 0, 0, 0 );
    + lastError = GetLastError();
    + status = QueryStatus( urlHandle );
    + if ( httpReq == TRUE && status == HTTP_STATUS_OK )
    + exitLoop = TRUE;
    + } else
    + exitLoop = TRUE;
    + }
    + }
    + }
    + return urlHandle;
    inline DWORD QueryStatus( HINTERNET id )

  • Scott Michel
    Scott Michel

    Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453.

  • Scott Michel
    Scott Michel

    @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-(

  • Keith Marshall
    Keith Marshall


    I am now ready to process your patch. After a preliminary review, I have the following comments:

    1) The change to dmh.cpp is unrelated to this issue, and is no longer relevant; its effect has already been incorporated while addressing another issue.

    2) I note, in your pkginet.cpp change,that you add the INTERNET_FLAG_EXISTING_CONNECT in the call to InternetOpenUrl. According to MSDN, this flag is useful only for FTP connections, and therefore would not be expected to offer any benefit here, where we are requesting an HTTP connection. Of course, we can't believe everything we read on MSDN; can you please confirm that using it here does deliver the claimed benefit?

    3) We cannot blithely use GetConsoleWindow in this context -- ultimately, this function may be called within a GUI context, with no attached console, so using it here isn't acceptable. This code needs to be factored out, into a context where it has been predetermined that we are running CLI or GUI. Furthermore, I don't think popping up a Windows dialogue box in a CLI context is particularly civilised; for a Q&D work around, it may be okay for the short term, but we should really be considering alternative methods for managing the proxy credentials.

    BTW, my employer's proxy credentials also change regularly, but AIUI, the PDC for the Windows Domain to which my user login is authenticated manages the propagation of the requisite settings changes to my registry configuration, as and when necessary, so apparently it is possible -- your employer's setup just doesn't do it.

  • Earnie Boyd
    Earnie Boyd

    > 2) I note, in your pkginet.cpp change,that you add the
    > INTERNET_FLAG_EXISTING_CONNECT in the call to InternetOpenUrl.
    > According to MSDN, this flag is useful only for FTP connections, and
    > therefore would not be expected to offer any benefit here, where we are
    > requesting an HTTP connection. Of course, we can't believe everything we
    > read on MSDN; can you please confirm that using it here does deliver the
    > claimed benefit?

    Keith, I believe the mirror redirect could end up with an FTP connection instead of an HTTP connection. Would this flag help that scenario?

  • Scott Michel
    Scott Michel


    INTERNET_FLAG_EXISTING_CONNECT: It doesn't affect functionality and could indicate to the HTTP provider that HTTP/1.1 persistent connections could/should be used. While the documentation may say FTP, my understanding is that it also true if HTTP/1.1 response headers are received. I'll kill it if it's really that much of an issue.

    Granted, the dialog has a "surprise" factor, but it only pops up once, even with my employer's wacky proxy credential system (think RSA keycards to ensure that a human is sitting in front of the screen.)

    If that's _really_ that much of an issue, I can find some time to implement a username and password prompt via the console. But really, why do that if MS-es API will handle that already (fewer things to maintain)?

1 2 > >> (Page 1 of 2)