Menu

#1497 No error message on failed download

Known_Feature
closed-fixed
2011-05-04
2010-12-29
Mike Hudson
No

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.

Discussion

  • Keith Marshall

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

    Keith Marshall - 2011-01-08

    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 - 2011-01-11

    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 - 2011-01-14

    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 - 2011-01-14

    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 @@
    ( "MinGW Installer", INTERNET_OPEN_TYPE_PRECONFIG,
    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.
    + */
    + DWORD urlFlags = INTERNET_FLAG_EXISTING_CONNECT;
    + 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,
    + FLAGS_ERROR_UI_FILTER_FOR_ERRORS |
    + FLAGS_ERROR_UI_FLAGS_CHANGE_OPTIONS |
    + FLAGS_ERROR_UI_FLAGS_GENERATE_DATA,
    + 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 - 2011-01-14

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

     
  • Scott Michel

    Scott Michel - 2011-01-14

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

     
  • Keith Marshall

    Keith Marshall - 2011-03-17

    Scott,

    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 - 2011-03-18

    > 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 - 2011-03-18

    @Keith:

    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)?

     
  • Keith Marshall

    Keith Marshall - 2011-03-18

    > INTERNET_FLAG_EXISTING_CONNECT:
    > I'll kill it if it's really that much of an issue.

    It's not an issue at all. I was just curious if you had any concrete evidence contrary to MSDN's indication that it is unlikely to have an effect in our scenario.

    > Granted, the dialog has a "surprise" factor

    It isn't so much the "surprise factor", as the irritation factor, when focus is snatched away from the CLI window, but even that is minor, in comparison to the need to call GetConsoleWindow(), to furnish the parent window handle for the dialogue; that simply will not be acceptable in this context, when we progress to the GUI implementation of mingw-get.

    > If that's _really_ that much of an issue, I can find some time to
    > implement a username and password prompt via the console.

    Or I can. If you would like to tackle it, please make sure you adhere to the style of the existing code; I will not incorporate your existing patch without extensive reformatting.

    > But really, why do that if MS-es API will handle that already
    > (fewer things to maintain)?

    Because that lazy approach exemplifies the worst in UI design.

     
  • Keith Marshall

    Keith Marshall - 2011-03-21

    Proposed provisional patch

     
  • Keith Marshall

    Keith Marshall - 2011-03-21

    Scott,

    As a first step, I propose application of the attached (heavily reformatted) variant of your original patch. Could you please test, and confirm that I haven't broken anything by rearrangement?

     
  • Keith Marshall

    Keith Marshall - 2011-04-04
    • status: open --> pending-fixed
     
  • Keith Marshall

    Keith Marshall - 2011-04-04

    Notwithstanding the lack of feedback on my revised implementation of Scott's patch, I've rolled it into mingw-get-2.0-alpha-3 anyway. Unless I get any feedback within the next thirty days, I'm going to assume that this is a satisfactory resolution to the reported problem, and allow the tracking robot to close this ticket.

     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 30 days (the time period specified by
    the administrator of this Tracker).

     
  • SourceForge Robot

    • status: pending-fixed --> closed-fixed