I am making a request to a remote server using https and request, and getting a new error after updating node and request:
nes.get err: [Error: 140735207432576:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:../deps/openssl/openssl/ssl/s23_clnt.c:741:
I already have the protocol set to SSLv3, so I'm wondering why it appears to be using tlsv1.
https.globalAgent.options.secureProtocol = 'SSLv3_method';
I've also tried adding this to request's options:
secureProtocol: 'SSLv3_method'
This error did not occur with earlier versions of Node.js and request, but now with node v0.10.15 and request 2.26.0, it has surfaced. Any ideas? Thanks!
Update -- narrowed this down to something that changes between request 2.14.0 and 2.16.0. 2.14.0 works and 2.16.0 does not work.
Make sure you are making a secure request to the correct port.
I've received this error when attempting to make a secure request to port 80 instead of port 443.
I would fire up Wireshark to verify that the bits on the wire are what you think they should be.
Related
I have the following setup:
Client => Proxy server => Origin Server
I'm using the following Node.js libraries for each of these pieces, respectively:
isomorphic-fetch => http-proxy => http
Here's a gist of the setup in two files, one for each of the servers and one for the client: https://gist.github.com/headquarters/850cbb199ff397c6da56fb8d86113a7e
To run this locally, run node server.js in one shell and node fetch.js in another shell.
With the servers running, if I go to http://localhost:8818 in a browser, I get the sample response {"a":"b"}, so that's working. If I go to http://localhost:9818, I also get that response, so the proxying appears to be working fine. However, if I run DEBUG=* node fetch.js, which includes the HTTP proxy agent, the request fails (see output at https://gist.github.com/headquarters/850cbb199ff397c6da56fb8d86113a7e#file-failure-txt).
Without the agent property, the fetch command works fine on the command line. How do I go about debugging this socket hang up error?
Turns out I didn't read the https-proxy-agent docs closely enough. This line was a bit confusing: An HTTP(s) proxy http.Agent implementation for HTTPS--the PROXY itself can be either HTTP or HTTPS, but the origin server has to be HTTPS for this flavor of proxy-agent. For an HTTP origin server, I had to use http-proxy-agent. Thus, the socket hang up was probably coming from https.Agent trying to access an HTTP endpoint. It worked when I switched to http-proxy-agent.
i found this sample code from github as chat-nodejs named and i want to test it how is it work, after installing socket.io and expressjs and running server and click to connect to server i get this error on firebug:
GET https://apis.google.com/_/scs/apps-static/_/js/k=...TcCOZ5yY8jtGvNKVwrKHFFcvb9eCe_w/cb=gapi.loaded_1
GET http://localhost/socket.io/?EIO=3&transport=polling&t=LbtPp7S
"NetworkError:404 Not Found -
http://localhost/socket.io/?EIO=3&transport=polling&t=LbtPp7S"?EIO=3&...LbtPp7S
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
http://localhost/socket.io/?EIO=3&transport=polling&t=LbtPp7S.
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
You're getting a NetworkError:404 Not Found because the serverAddress in Line 15 of chat.io.js doesn't have the server port 8080 in it. Add port number to it.
serverAddress = 'http://localhost:8080',
Additionally, socket.io might not work well if the client and server installation of it, are of different version.
index.html doesn't use a local one. The recent version of socket.io dint work for this repo. I had to install 0.9.13 on the server side for it to work.
I am facing this issue while making a request to any url using NodeJS.
FYR i have made a script in nodejs which is using request module that calls a page and then scrap that html page but the issue is when it calls i gets an error "Error: Invalid protocol: 10.112.62.78".
My .npmrc file contains following lines
proxy=http://10.112.62.78:8080
https-proxy=http://10.112.62.78:8080
registry=http://registry.npmjs.org/
and i still get following error
[Error: Invalid protocol: 10.112.62.78:]
I have tried all possible combinations of following
http://user:password#proxy:port
http://"user:password"#proxy:port
For the above two i get "URI Malformed error"
Still no solution
http://proxy.company.com:port
FYI Versions are as follows:
>node -v
>v0.12.0
>npm -v
>2.5.1
There is one more info i have static ip of 10.112.111.86 in IPv4 and ip of 10.112.62.78 with 8080 in Proxy Setting of Browser . Also i am using Windows 7 desktop and i tried with Proxy IP of 10.112.62.78 & without it but no solution however i can't change the IPv4 otherwise my internet connection would be gone.
Please provide some solution i am stuck.
PS: Also tried by changing http To https for https-proxy .
Npmrc is used by npm, not (afaik) requests within your node code, so this is probably a red herring. What code are you using to make the request?
I have one Custom Linux board on which I want to
run apache web server (httpd) to test HTML
and other web based pages.
I have configured, cross compiled and installed httpd (2.2.24, 2.4.1, 2.4.4 and 2.4.9 packages) on my Linux PC (Ubuntu 12.04 LTS) as well as
on my own custom Linux board. Then I have added support of SSL Module (mod_ssl) to test HTTP as well as HTTPS request.
Both HTTP and HTTPS request works fine without any issue on my Linux PC (Ubuntu 12.04 LTS). But when I tried to execute same HTTP request
on my Linux Board using httpd (2.4.4 and 2.4.9 with SSL Module Enabled) at that time browser page goes into loading state and can not be came out from that situation.
Also I have seen that HTTPS request works fine at that time ( not HTTP )
I have also did some debugging task through wire-shark tool and found that connection is established successfully after sending request through HTTP
but can not get response of that request. I have also found that response of that HTTP request received on wire-shark after closing that HTTP
requested page from browser.
Also, I can run HTTP and HTTPS requests successfully using httpd (2.2.24 and 2.2.27 with SSL Module enabled) on my Linux Board as well but failed to execute same request
using httpd (2.4.X with SSL Module enabled) package.
I have also changed some configurations by creating different virtual host for HTTP (Port 80) and HTTPS (Port 443) but still failed to
execute that HTTP request.
I have also tried to listen on different ports like (Listen 80 and Listen 8000) without SSL module (using httpd 2.4.4. and 2.4.9 ) at that
time HTTP request goes into loading state.
Basically all thing works in version 2.2.x but not in 2.4.x.
Does anyone has idea about this issue or help me to solve this type of issue?
I have faced similar type of problem while requesting HTTP Page on multiple Listen Directive in my custom linux board.
Please configure APR Package with ac_cv_o_nonblock_inherited=no flag and configured int with httpd package which will solve HTTP request failed issue on multiple Listen Port.
I have a RHEL5 server in a private zone. I've set up a transparent proxy for ports 80 and 443. When I try a wget on 443, I get the following:
# wget -O- https://www.google.com
--2013-02-14 15:16:50-- https://www.google.com/
Resolving www.google.com... 74.125.129.147, 74.125.129.104, 74.125.129.106, ...
Connecting to www.google.com|74.125.129.147|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.
I assume the proxy works because it's connecting. I don't know what else could be causing this.
This OpenSSL error indicates that wget sent the initial SSL ClientHello message, but gets an unexpected response from the server (or proxy) which was not an SSL ServerHello message.
This can be because the proxy speaks plain HTTP with the client, instead of HTTPS, because of a configuration error (e.g. with squid if port 443 is redirected to a http_port instead of https_port with the transparent option), or because it does not support transparent proxying of SSL at all. To debug, you may try connecting to http://www.google.com:443/ to see what happens. To know what's going on, you might want to run tcpdump while connecting to see what the server responds with. Also check the error log of your transparent proxy.
Without the transparent proxy configuration it is hard to tell what the problem is.