From: SF/projects/mingw n. l. <min...@li...> - 2010-12-29 21:17:56
|
Bugs item #3147803, was opened at 2010-12-29 16:17 Message generated for change (Tracker Item Submitted) made by belgarionthekin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Nobody/Anonymous (nobody) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-08 23:31:00
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer >Group: Known Feature Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) >Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-11 15:25:40
|
Bugs item #3147803, was opened at 2010-12-29 16:17 Message generated for change (Comment added) made by belgarionthekin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 10:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 18:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-14 20:42:39
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by pingbak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-14 20:44:41
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by pingbak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-14 20:54:58
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by pingbak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-01-14 21:03:28
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by pingbak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 21:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-03-17 22:54:11
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2011-03-17 22:54 Message: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 21:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-03-18 13:25:55
|
Bugs item #3147803, was opened at 2010-12-29 16:17 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2011-03-18 09:25 Message: > 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-17 18:54 Message: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 16:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 15:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 15:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 15:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 10:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 18:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-03-18 16:50:25
|
Bugs item #3147803, was opened at 2010-12-29 13:17 Message generated for change (Comment added) made by pingbak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-03-18 09:50 Message: @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)? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-03-18 06:25 Message: > 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-17 15:54 Message: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 13:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 12:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 12:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 12:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 07:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 15:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-03-18 22:16:47
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2011-03-18 22:16 Message: > 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-03-18 16:50 Message: @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)? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-03-18 13:25 Message: > 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-17 22:54 Message: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 21:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-03-21 22:15:41
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature Status: Open Resolution: None Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2011-03-21 22:15 Message: 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-18 22:16 Message: > 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-03-18 16:50 Message: @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)? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-03-18 13:25 Message: > 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-17 22:54 Message: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 21:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2011-05-04 12:20:06
|
Bugs item #3147803, was opened at 2010-12-29 21:17 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: Known Feature >Status: Closed Resolution: Fixed Priority: 3 Private: No Submitted By: Mike Hudson (belgarionthekin) Assigned to: Keith Marshall (keithmarshall) Summary: No error message on failed download Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-05-04 12:20 Message: 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). ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-04-04 11:27 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-21 22:15 Message: 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-18 22:16 Message: > 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-03-18 16:50 Message: @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)? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-03-18 13:25 Message: > 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? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-03-17 22:54 Message: 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. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 21:03 Message: @Keith: My employer's proxy password changes on a daily basis, so no creds can be cached in the registry. :-( ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:54 Message: Ok, I'm a bit of an idiot today. Found where to upload patches, see patch 3158453. ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:44 Message: 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 ) { ---------------------------------------------------------------------- Comment By: Scott Michel (pingbak) Date: 2011-01-14 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Mike Hudson (belgarionthekin) Date: 2011-01-11 15:25 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-01-08 23:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3147803&group_id=2435 |