legacy proxy support #2866

nwinkler opened this Issue Oct 9, 2012 · 50 comments

I have set up my .npmrc file to have settings for our corporate proxy:

proxy = http://user:password@proxy:8080/
https-proxy = http://user:password@proxy:8080/

Running any npm command using these settings fails. As a workaround, I had to change the registry to HTTP instead of HTTPS:

registry = http://registry.npmjs.org/

Most things seem to work fine with this, except if I try to install something that has dependencies listed using HTTPS. One example for this is Yeoman (https://github.com/yeoman/yeoman), which lists two dependencies in package.json using HTTPS:


Downloading these fails miserably with the following error:

npm ERR! fetch failed https://nodeload.github.com/cowboy/grunt/tarball/0ba6d4b529
npm ERR! fetch failed https://nodeload.github.com/yeoman/generators/tarball/282b0b4c51
npm ERR! Error: tunneling socket could not be established, sutatusCode=403
npm ERR!     at ClientRequest.onConnect (/usr/local/lib/node_modules/npm/node_modules/request/tunnel.js:148:19)
npm ERR!     at ClientRequest.g (events.js:193:14)
npm ERR!     at ClientRequest.EventEmitter.emit (events.js:123:20)
npm ERR!     at Socket.socketOnData (http.js:1393:11)
npm ERR!     at TCP.onread (net.js:403:27)
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>

npm ERR! System Darwin 10.8.0
npm ERR! command "node" "/usr/local/bin/npm" "install" "yeoman"
npm ERR! cwd /Users/Nils.Winkler
npm ERR! node -v v0.8.11
npm ERR! npm -v 1.1.62

It seems like HTTPS does not work through some proxies. Could you please look into getting this supported in npm, as it looks like a major shortcoming for people behind a corporate proxy.


Any workaround for this issue?


I haven't found any workaround, other than patching the Yeoman package.json to remove the HTTPS part and then installing locally, which is ugly.


Here's some more info on this (from Wireshark).

When doing an HTTP request over a proxy, npm does a direct GET on the URL:

GET http://registry.npmjs.org/yeoman HTTP/1.1

When doing an HTTPS request over a proxy, npm does not do a direct GET, but tries to tunnel the request using a CONNECT request (e.g. for https://nodeload.github.com/yeoman/generators/tarball/282b0b4c51):

CONNECT nodeload.github.com:443 HTTP/1.1

It looks like this CONNECT does not work, as the proxy replies with

HTTP/1.1 403 Forbidden

I tried the same URL from a web browser that connects using the same proxy, and I noticed that it was also using the same CONNECT mechanism. There was a small difference in the parameters, which might cause the 403. The browser had some different parameter in the CONNECT request:

  • Host: npm was sending the name of the proxy in this field, while the browser was sending the name of the target host (nodeload.github.com)
  • Connection: npm was sending "close", while the browser was not using this field
  • Proxy-Connection: npm was not using this field, while the browser was sending "keep-alive" here.

To me, it looks like the tunneling approach is using some specific settings that do not work with our proxy. While similar to the way it's implemented in web browsers, there seem to be some settings that cause the proxy to reply with a 403.


+1 on this issue.

@nwinkler nwinkler referenced this issue in request/request Nov 9, 2012

HTTPS does not work through Proxy #367


+1 - Facing the same behavior with 0.8.14


Fixed for me trough using .npmrc .

An automation trough using system wide variables, and using the system proxy (e.g on unix/linux machines)
is still needed as an essential function for me.

Can I do a seperate bug report for that?

npm member

@gotwig whatever you can put in your .npmrc file you can also put in environment variables or command line options. You can also specify an alternative file to use for .npmrc using an option. See npm help config. Those should be sufficient for your use case as you described it.


So, why do the environmental variables not get used by default?

npm member

What do you mean by "by default"? Environment variables are used if you set them, subject to the prioritisation of config sources described in the help. They are second only to command line options.


I am just wondering why I have to set up extra proxy settings for NPM, when all other applications (that work normally with Linux/ubuntu system proxy) work fine


I'm guessing part of the original idea behind this was to keep the npm codebase simpler by not looking for platform specific proxy settings (which is not a small task).

npm member

The standard env vars for this are http_proxy and https_proxy - shouldn't we already be handling those?

@dschulten dschulten referenced this issue in creynders/jsfsa May 1, 2013

Cannot define effect and guard on transition #5


nathan7, the environment variables are being handled just fine. The issue is that https requests themselves are being handled incorrectly, such that they can't be completed through whatever proxy you set.

This is still an issue, and it sounds like a huge one.

npm member

If any of our contributors is to fix this, it would help if someone created a public proxy server that could demonstrate the issue. Then you could give us repro steps like "set https_proxy to "http://my-proxy.jit.su", run npm install yeoman, see failure. set https_proxy to "", run npm install yeoman, see success."

Tagging "repro-please" until we can get something like this set up, as without it none of npm contributors are going to be able to work on this. If the bug is important to you, please investigate setting up such a public proxy and demonstrating some clear repro steps.


Same issue, on a win7 box. Set both HTTPS_PROXY and HTTP_PROXY (with AD domain),

tried to npm tet things like:
npm http GET https://registry.npmjs.org/less


360 error Error: tunneling socket could not be established, cause=Parse Error
360 error at ClientRequest.onError (C:\Program Files\nodejs\node_modules\npm\node_modules\request\node_modules\tunnel-agent\index.js:159:17)
360 error at ClientRequest.g (events.js:175:14)
360 error at ClientRequest.EventEmitter.emit (events.js:95:17)
360 error at Socket.socketOnData (http.js:1569:9)
360 error at TCP.onread (net.js:525:27)
361 error If you need help, you may report this log at:
361 error http://github.com/isaacs/npm/issues
361 error or email it to:
361 error npm-@googlegroups.com
362 error System Windows_NT 6.1.7601
363 error command "C:\Program Files\nodejs\\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "install"
364 error cwd C:\kendo-bootstrapper
365 error node -v v0.10.13
366 error npm -v 1.3.2
367 error code ECONNRESET
368 verbose exit [ 1, true ]


I can also confirm it is an https issue, since setting registry to http://registry.npmjs.org/ works fine. I used

npm config set proxy http://DOMAIN%20username:password@servername:port
npm config set https-proxy http://DOMAIN%20username:password@servername:port

npm config set registry http://registry.npmjs.org/

then installed the kendo ui bootstrapper


@DrYSG DrYSG referenced this issue in kendo-labs/kendo-bootstrapper Jul 25, 2013

Novice users issues #31

npm member

@DrYSG per #2997:

You need to url-encode the \ character. http://AD%5Cusername:passwd@

I upgraded to node.js, v0.10.17 and I am getting this issue again.

npm config set proxy http://DOMAIN%5Cusername:password@servername:port
npm config set https-proxy http://DOMAIN%5Cusername:password@servername:port

npm config set registry http://registry.npmjs.org/

Should it not be directing the https to http?



request/tunnel-agent#6 should fix this.

Can the patch be pulled into deps/ ?


I am a newbie, but I would like to try this out. I tried >npm install -g on tunnel-agent but I still get the above error when I subsequently try to install PostGreSQL for node.


@DrYSG you need to apply the patch since it's not merged into master and published yet.

Unfortunately, I don't know of a way you can try this patch without compiling node yourself.

  • Compile node
  • Apply patch in tunnel-agent. deps/npm/node_modules/request/node_modules/tunnel-agent/index.js is the path in node code.

That is a bit beyond me right now, but there is any need for alpha/beta testing a patched version, I will gladly help. What would also be nice if if I could stick Fiddler in the loop and watch the HTTPS traffic:


I have another issue oepn with node-gyp and he is telling me that this can be fixed by setting the HTTPS_PROXY environment variable. nodejs/node-gyp#312 (comment)
Does that make sense to you?

set HTTP_PROXY=http://DOMAIN\username:password@servername:port
set HTTPS_PROXY=http://DOMAIN\username:password@servername:port

(Should the backslash be escaped as %05? )


Escaping backslash to %5C did not help.


@crimar crimar referenced this issue in request/tunnel-agent Nov 1, 2013

agent.addRequest parameters have changed #6


I might have missed this, but is there any change with this ticket? I currently have npm version 1.3.14, and I still have the same issue.

Is the above fix supposed to fix the issue, so that HTTPS works over the HTTP proxy as well? I did some further debugging today, and I'm not sure why it's not working:

  • HTTP over HTTP proxy works fine
  • HTTPS over HTTP proxy does not work with our proxy

Here's what the tunnel-agent module uses to connect when I try to access https://registry.npmjs.org from a unit test:

The error message shown is:

[Error: tunneling socket could not be established, statusCode=407] code: 'ECONNRESET' 

Well, for the nature of HTTPS (Proxy are not allowed to read) the proxy protocol for encrypted HTTP request are different.

There were steps for reproduction requested. May be this set up hint works for you. I did took a Apache2 on a Ubuntu PC. I enabled the following mods:

  • proxy.load
  • proxy_connect.load
  • proxy_ftp.load
  • proxy_ftp.conf
  • proxy_http.load
  • status.load (Optional for observing the Proxy)
  • status.conf (Optional for observing the Proxy)

Here the equivalent configuration lines:

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_connect_module /usr/lib/apache2/modules/mod_proxy_connect.so
LoadModule proxy_ftp_module /usr/lib/apache2/modules/mod_proxy_ftp.so
<IfModule mod_proxy_ftp.c>
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so
# Define the character set for proxied FTP listings. Default is ISO-8859-1
ProxyFtpDirCharset UTF-8

Optional parts:

LoadModule status_module /usr/lib/apache2/modules/mod_status.so
<IfModule mod_status.c>
# Allow server status reports generated by mod_status,
# with the URL of http://servername/server-status
<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from ::1
ExtendedStatus On
# Determine if mod_status displays the first 63 characters of a request or
# the last 63, assuming the request itself is greater than 63 chars.
# Default: Off
#SeeRequestTail On
<IfModule mod_proxy.c>
    ProxyStatus On

That are the basics. Now we make a apache site for the Proxy:

        <IfModule mod_proxy.c>
        ProxyRequests On
        ProxyVia On
        <Proxy *>
                Order deny,allow
                Deny from all
                Allow from
        ErrorLog ${APACHE_LOG_DIR}/proxy-error.log
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/proxy-access.log combined

As you can see the configuration is for the localhost. If you are using an other server for the proxy than your development PC then you can us the SSH portforwarding for this. The proxy port is 3128. The log files contained in /var/log/apache2. The status page is http://localhost:3128/server-status.

I hop this is enough detailed and every contributor can reproduce it. I give npm such a proxy and in the log file you can see hexadecimal character instead of a CONNECT command.


I'm facing exactly the reported issue behind a corporate proxy. Setting strict-ssl=false and using the non-SSL HTTP npm registry only defers the failure.

  1. Is there a working workaround at all?
  2. What's going wrong in the first place regarding the SSL connection? Never had any issues with other programs on accessing https-based content through the proxy.

I had similar issues here. Here is the solution I found that works for me (Windows 7).

I installed and configured cntlm (may not be an option for those without admin rights, but there is a portable version which should work just as well).

Now, find and fill in these fields in cntlm.ini. It is best to not fill in the Password field, as this value will be exposed in plain text:

Field Value
Listen SOME_FREE_PORT (e.g. 3128)

From a console (cmd.exe), type the following commands to generate password hashes (protects your password):

cntlm -H
PassLM               FE03A594184396D6552C4BCA4AEBFB11
PassNT               F3496B77FA086840D57D7F868C476AC8
PassNTLMv2      9E0497049E7F55217C1CF5686D2EFF03

Copy the last three lines (from PassLM through to the end of PassNTLMv2) and paste these into your cntlm.ini file, under the Domain field's line.

Open the Service Manager (from command line: services.msc), and start the service called "CNTLM Authentication Proxy".

In the console, type these lines (note in the second line the value of https-proxy does not have 'https://', it has 'http://' - this was key for me):

npm config set proxy http://localhost:YOUR_LISTEN_PORT_VALUE_FROM_ABOVE
npm config set https-proxy http://localhost:YOUR_LISTEN_PORT_VALUE_FROM_ABOVE
npm config set registry "http://registry.npmjs.org/"

In my case, this looks like:

npm config set proxy http://localhost:3128
npm config set https-proxy http://localhost:3128
npm config set registry "http://registry.npmjs.org/"

Now, all should work.

(credit to http://www.unknownerror.org/Problem/index/1548531615/npm-behind-ntlm-proxy/ for some guidance)

DVG commented May 7, 2014

+1 This pretty much makes using npm impossible in a corporate environment.


+1 on this issue.
4395 http GET https://github.com/LearnBoost/node-XMLHttpRequest/archive/0f36d0b5ebc03d85f860d42a64ae9791e1daa433.tar.gz
4396 error fetch failed https://github.com/LearnBoost/node-XMLHttpRequest/archive/0f36d0b5ebc03d85f860d42a64ae9791e1daa433.tar.gz
4417 error network tunneling socket could not be established, cause=140662149818144:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:787:


I face the same problem on NPM 4.414 on win7, but find the workaround by
set npm_config_https_proxy=http://proxy:8080. then it works.


npm ERR! fetch failed https://github.com/LearnBoost/node-XMLHttpRequest/archive/0f36d0b5ebc03d85f860d42a64ae9791e1daa433.tar.gz
I also have the same problem,my os is ubuntu 12.04,I don't much understand what said above,someone can tell me how to fix it?

@jianghaolu jianghaolu referenced this issue in Azure/azure-xplat-cli Jul 16, 2014

Proxy support needed #1163


👍 I believe that I am also experiencing this issue (see https://discuss.atom.io/t/error-while-attempting-to-build-atom-behind-proxy/10927/3 for details).

I'm not familiar with wireshark, so I have not been able to confirm the cause of the problem as described by @nwinkler.

I am already using CNTLM as suggested by @adpd, and have been for some time. This did not solve the problem for me.

Other applications like curl and Chrome are able to access https resources with no problems (and no additional configuration on my part). I have not been able to get SSH working for resources outside the proxy (like git clone urls using the git:// protocol).

Were any npm contributors able to reproduce the problem using the steps described by @12delta?




It's possible this might be a core node issue for some people.

From what I could tell, it seemed like the tunnel-agent relies on the Node http client which in turn relies on http-parser.

As noted elsewhere, then making an HTTPS request through an HTTP proxy config, the request is first sent with a CONNECT method. It's possible that the proxy server is responding with something the parser doesn't like.

I didn't have time to dig into things more, but it would be interesting to see if anyone's proxy is responding with a 200 status code. I know @nwinkler indicated a 403 response - in which case it seems there is no hope.

http: HPE_INVALID_CONSTANT parse error if CONNECT response contains body #7019

@othiym23 othiym23 added this to the 2.1.0 milestone Sep 21, 2014

Is this still an issue as of npm@2.0.0? I've upgraded the version of request npm is using several times over the npm 2 development cycle, and it's incorporated many small tweaks to both proxying and the tunnel agent.

If you are still seeing this problem, we're still in need of a good, deterministic repro case that we can use to troubleshoot both how we're configuring our proxy settings, and whatever a given version of node and request are doing. @domenic's request above still holds. When I have a little more time, I'll see if @12delta's walkthrough creates a reproducible issue, but I would still like to know what node and npm versions people are seeing these issues with. It really does make a difference.

@othiym23 othiym23 added the enterprise label Sep 21, 2014

I did try it again with my apache proxy (with by Web-Browser to check the proxy is working and with npm). Here are som Log information:

user@host:~/node-v0.10.32-linux-x64$ npm config list
; cli configs
registry = "https://registry.npmjs.org/"
user-agent = "npm/2.0.0 node/v0.10.32 linux x64"

; userconfig /home/user/.npmrc
https-proxy = "https://localhost:3128/"
proxy = "http://localhost:3128/"

; node bin location = /home/user/node-v0.10.32-linux-x64/bin/node
; cwd = /home/user/node-v0.10.32-linux-x64
; HOME = /home/user
; 'npm config ls -l' to show all defaults.

user@host:~/node-v0.10.32-linux-x64$ npm search proxy
npm WARN Building the local index for the first time, please be patient
npm ERR! Linux 3.13.0-35-generic
npm ERR! argv "node" "/home/user/node-v0.10.32-linux-x64/bin/npm" "search" "proxy"
npm ERR! node v0.10.32
npm ERR! npm  v2.0.0

npm ERR! network tunneling socket could not be established,    cause=140052124645248:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:787:
npm ERR! network
npm ERR! network This is most likely not a problem with npm itself
npm ERR! network and is related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly.  See: 'npm help config'

npm ERR! Please include the following file with any support request:
npm ERR!     /home/user/node-v0.10.32-linux-x64/npm-debug.log
user@host:~/node-v0.10.32-linux-x64$ npm version
{ http_parser: '1.0',
  node: '0.10.32',
  v8: '',
  ares: '1.9.0-DEV',
  uv: '0.10.28',
  zlib: '1.2.3',
  modules: '11',
  openssl: '1.0.1i',
  npm: '2.0.0' }

23 verbose stack
23 verbose stack     at ClientRequest.onError (/home/user/node-v0.10.32-linux-x64/lib/node_modules/npm/node_modules/request/node_modules/tunnel-agent/index.js:168:17)
23 verbose stack     at ClientRequest.g (events.js:180:16)
23 verbose stack     at ClientRequest.emit (events.js:95:17)
23 verbose stack     at CleartextStream.socketErrorListener (http.js:1551:9)
23 verbose stack     at CleartextStream.emit (events.js:95:17)
23 verbose stack     at SecurePair.<anonymous> (tls.js:1397:15)
23 verbose stack     at SecurePair.emit (events.js:95:17)
23 verbose stack     at SecurePair.error (tls.js:1017:27)
23 verbose stack     at CleartextStream.read [as _read] (tls.js:462:17)
23 verbose stack     at CleartextStream.Readable.read (_stream_readable.js:340:10)

Do this help?

@othiym23 othiym23 self-assigned this Sep 22, 2014
@othiym23 othiym23 added the ready label Sep 22, 2014

@12delta It does, although I would say that npm search is a particularly brutal test for a proxy, because it tends to be a very long-lived connection moving a lot (~35MiB) of data. I'll see about using your (very thorough! thank you!) instructions to set up a test environment and see what needs to happen from there.

It may take me a few weeks to get to this, just FYI.


A simpler proxy setup is achievable using Docker.
sudo docker run -d -p 8765:8888 paintedfox/tinyproxy
You can ensure the proxy is running with nc localhost 8765 then hit enter a few times.
Then use @12delta's method of setting the proxy

; userconfig /home/user/.npmrc
https-proxy = "https://localhost:8765/"
proxy = "http://localhost:8765/"

The error may now be invoked npm search proxy

@othiym23 othiym23 added the next-minor label Oct 7, 2014
@othiym23 othiym23 removed this from the 2.2.0 milestone Oct 7, 2014
@othiym23 othiym23 removed the repro-please label Oct 7, 2014


Trying to install https://github.com/erming/shout but getting this dreaded-no-decent-workaround issue.

npm ERR! fetch failed http://github.com/component/emitter/archive/1.0.1.tar.gz
npm http GET https://github.com/LearnBoost/node-XMLHttpRequest/archive/0f36d0b5ebc03d85f860d42a64ae9791e1daa433.tar.gz
npm ERR! fetch failed https://github.com/LearnBoost/node-XMLHttpRequest/archive/0f36d0b5ebc03d85f860d42a64ae9791e1daa433.tar.gz
npm http GET http://github.com/component/emitter/archive/1.0.1.tar.gz
npm ERR! fetch failed http://github.com/component/emitter/archive/1.0.1.tar.gz
npm ERR! network tunneling socket could not be established, cause=Parse Error
npm ERR! network This is most likely not a problem with npm itself
npm ERR! network and is related to network connectivity.

Apologies if i'm writing to wrong issue but i've solved my problem and maybe what i did can help anyone else. I'm unfortunately in corporate proxy, using ubuntu in virtualbox (proxy settings written to ubuntu network settings) and somehow got the same error messages written in this issue.
Here's how i've solved:

npm config set strict-ssl false
npm config set proxy http://username:password@proxy.company.com:port
npm config set https-proxy https://username:password@proxy.company.com:port
npm config set registry "http://registry.npmjs.org/"


Well, you are actually only avoiding the issue. By specifying HTTP as the protocol for the registry, you're not using HTTPS, and you're therefore not running into the issue.

This ticket is about fixing that using HTTPS when running behind a proxy does not work.


I'm using cntml as well behind our coporate proxy, i was having the same issue as nwinkler, i have resolved this issue by adding (commenting out) header property in the cntml ini file
Header User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

it seems our corporate proxy only accepts http connect command from browsers.


Thanks @emrecamasuvi, works for me as well.


I'm also having this issue when trying to create a new project using ember-cli behind a Squid proxy. Setting http_proxy, https_proxy, registry "http://registry.npmjs.org/" or strict-ssl false in .npmrc makes it advance further, but it fails anyway when trying to get a dependency using https.

Installed packages for tooling via npm.
Request to https://bower.herokuapp.com/packages/handlebars failed: tunneling socket could not be established, cause=139751947282304:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:

Error: Request to https://bower.herokuapp.com/packages/handlebars failed: tunneling socket could not be established, cause=139751947282304:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:

    at createError (/usr/local/lib/node_modules/ember-cli/node_modules/bower/node_modules/bower-registry-client/lib/util/createError.js:2:15)
    at Request._callback (/usr/local/lib/node_modules/ember-cli/node_modules/bower/node_modules/bower-registry-client/lib/lookup.js:98:29)
    at self.callback (/usr/local/lib/node_modules/ember-cli/node_modules/bower/node_modules/bower-registry-client/node_modules/request/request.js:373:22)
    at Request.EventEmitter.emit (events.js:95:17)
    at Request.request.emit (/usr/local/lib/node_modules/ember-cli/node_modules/bower/node_modules/bower-registry-client/node_modules/request-replay/index.js:89:29)
    at Request.onRequestError (/usr/local/lib/node_modules/ember-cli/node_modules/bower/node_modules/bower-registry-client/node_modules/request/request.js:971:8)
    at ClientRequest.EventEmitter.emit (events.js:95:17)
    at ClientRequest.onError (/usr/local/lib/node_modules/ember-cli/node_modules/bower/node_modules/bower-registry-client/node_modules/request/node_modules/tunnel-agent/index.js:170:21)
    at ClientRequest.g (events.js:180:16)
    at ClientRequest.EventEmitter.emit (events.js:95:17)
npm member


Request to https://bower.herokuapp.com/packages/handlebars failed: tunneling socket could not be established, cause=139751947282304:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:

Error: Request to https://bower.herokuapp.com/packages/handlebars failed: tunneling socket could not be established, cause=139751947282304:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:

These requests to bower.herokuapp.com are definitely not npm's fault.


@dgaus what @KenanY says is true. You might try setting HTTP_PROXY and / or HTTPS_PROXY in your environment rather than directly via npm's configuration, because the recent versions of request used by recent versions of npm will pick up proxy settings from the environment. Also, for some of the Bower stuff, setting https.insteadOf.git in your git configuration may help (although it looks like this has also been addressed by the Bower team directly).

Good luck!


@othiym23 @KenanY You are absolutely right, thanks, sorry for the noise!

@othiym23 othiym23 removed their assignment Apr 23, 2015
@othiym23 othiym23 removed the ready label Apr 23, 2015
@kkoopa kkoopa referenced this issue in brianmcd/contextify Jun 11, 2015

Windows 7 Installation Error #169

@othiym23 othiym23 changed the title from HTTPS does not work through Proxy to legacy proxy support Aug 24, 2015

This has been moved to the npm roadmap, which we're using instead of the confusing next-* labels now.

@othiym23 othiym23 removed the next-minor label Aug 24, 2015

@othiym23 Thanks for adding this to the roadmap! It still is an annoying issue for people having to work with a corporate proxy...


Any news here?

I solved it using Fiddler and its "Automatically Authenticate" rule as a local proxy for our corporate proxy, but that's not very handy since I've to start up Fiddler and disable HTTPS decryption before using npm. Every time.

By the way, disabling HTTPS or saving my password in plaintext as described many times is not an option...

@fvaleri fvaleri referenced this issue in apache/zeppelin Jun 27, 2016

[ZEPPELIN-281] Windows7 build2 #1069

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment