Project:Drush
Version:5.x-1.3
Component:PM (dl, en, up ...)
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed (won't fix)
Issue tags:drush, proxy, wget

Issue Summary

Would you consider adding proxy support? I absolutely love Drush, however it doesn't work on my home computer that's behind a proxy. I have applied a patch to my setup that allows drupal_http() requests to support proxies, however drush must be using something else.

Thanks,
JacobWG

Comments

#1

Status:active» closed (fixed)

drush_pm just uses update_status module for communicating with drupal.org. please ask there.

#2

Status:closed (fixed)» active

I may be mistaken, but doesn't update_status use a cvs, wget, or curl command that might have proxy settings?

JacobWG

#3

Status:active» postponed (maintainer needs more info)

Is the issue in fetching the update information (drush refresh), or in downloading the actual update tarballs themselves? If the former then it is an update_status/core issue - if the latter, then we can help.

#4

Status:postponed (maintainer needs more info)» active

It is an issue with the downloading of the tar files. However, I am not using a proxy anymore and am also on Drupal 6, so this might be a really old request.

Thanks anyway!

JacobWG

#5

Status:active» needs review

To sort out the problems with the downloading of tarballs via wget with drush from behind a proxy, you need to add the proxy server settings to your .wgetrc file.

  • On Windows, create a new file in your HOME path named "%HOMEDRIVE%%HOMEPATH%\.wgetrc"
  • On Linux/Cygwin create a new file in your home path named ~/.wgetrc

and add the following lines, where {PORT} is the port number of your proxy server:

http_proxy=http://username:password@http.proxy.server:{PORT}
ftp_proxy=http://username:password@ftp.proxy.server:{PORT}
use_proxy=on

#6

Status:needs review» postponed (maintainer needs more info)
Issue tags:-configure, -setUp

I think proxy settings could be considered as being outside the scope of Drush, @jacobwg - would that be sufficient for you?

(Does curl or php-curl support such configurations?)

#7

Status:postponed (maintainer needs more info)» closed (won't fix)

Yes, that is sufficient; I actually haven't been behind a proxy since 2008 :)

Here's some info on the curlrc file from the curl man page:

-K/--config <config file>

Specify which config file to read curl arguments from. The  con-
fig  file  is a text file in which command line arguments can be
written which then will be used as if they were written  on  the
actual command line. Options and their parameters must be speci-
fied on the same config file line,  separated  by  white  space,
colon,  the equals sign or any combination thereof (however, the
preferred separator is the equals sign). If the parameter is  to
contain  white  spaces,  the  parameter  must be enclosed within
quotes. Within double quotes, the following escape sequences are
available:  \\,  \", \t, \n, \r and \v. A backlash preceding any
other letter is  ignored. If the first column of a  config  line
is  a  '#'  character, the rest of the line will be treated as a
comment. Only write one option per physical line in  the  config
file.

Specify the filename to -K/--config as '-' to make curl read the
file from stdin.

Note that to be able to specify a URL in the  config  file,  you
need  to  specify  it  using the --url option, and not by simply
writing the URL on its own line. So, it could  look  similar  to
this:

url = "http://curl.haxx.se/docs/"

Long  option  names  can  optionally be given in the config file
without the initial double dashes.

When curl is invoked, it always (unless -q is used) checks for a
default  config  file  and  uses it if found. The default config
file is checked for in the following places in this order:

1) curl tries to find the "home dir": It first  checks  for  the
CURL_HOME and then the HOME environment variables. Failing that,
it uses getpwuid() on unix-like systems (which returns the  home
dir  given the current user in your system). On Windows, it then
checks for the APPDATA variable, or as a last resort the '%USER-
PROFILE%0lication Data'.

2)  On  windows, if there is no _curlrc file in the home dir, it
checks for one in the same dir the executable curl is placed. On
unix-like  systems,  it will simply try to load .curlrc from the
determined home dir.

# --- Example file ---
# this is a comment
url = "curl.haxx.se"
output = "curlhere.html"
user-agent = "superagent/1.0"

# and fetch another URL too
url = "curl.haxx.se/docs/manpage.html"
-O
referer = "http://nowhereatall.com/"
# --- End of example file ---

This option can be used multiple times to load  multiple  config
files.

So, that should mean that any of the proxy command line options below could be added to the .curlrc file:

-x/--proxy <host[:port]> Use HTTP proxy on given port
    --proxy-anyauth Pick "any" proxy authentication method (H)
    --proxy-basic   Use Basic authentication on the proxy (H)
    --proxy-digest  Use Digest authentication on the proxy (H)
    --proxy-negotiate Use Negotiate authentication on the proxy (H)
    --proxy-ntlm    Use NTLM authentication on the proxy (H)
-U/--proxy-user <user[:password]> Set proxy user and password
-p/--proxytunnel   Operate through a HTTP proxy tunnel (using CONNECT)

#8

#9

Component:Code» PM (dl, en, up ...)
Issue tags:+drush, +wget

In my case I do not need the username:password this works as my .wgetrc

http_proxy=http://IP_ADDRESS:80
ftp_proxy=http://IP_ADDRESS:80
use_proxy=on

where IP_ADDRESS is the IP number; and the port is 80

I also had to create C:\tmp for Drush and make it writeable

(Windows 7 32 bit behind a corporate firewall)