I successfully tested the OCPP server by mobility house integrated with aiohttp API in local network. But now I am deploying the websocket server integrated with the HTTP API to Heroku and the Chargepoint script connects to the websocket server successfully and OCPP is happening but the HTTP endpoint is not reachable through curl through CMD by using the domain name URL. Actually this was working perfectly when I reached the HTTP server in local network using curl localhost:PORT command in CMD. But after deploying it is not.
On the server log It displays this:
heroku[router]: at=info method=POST path="/reset" host=ocpp.herokuapp.com request_id=43e705f-85c-48f-8273-002e5e9f3ed8 fwd="22.22.216.2" dyno=web.1 connect=0ms service=1ms status=400 bytes=242 protocol=http
As seen above the http connection is received but it is not doing anything.
On the CMD curl Output was this:
Failed to open Websocket connection: did not receive a valid http request.
I am using the below mentioned type of code for this:
https://github.com/mobilityhouse/ocpp/issues/86#issuecomment-620205346
Thanks people for any time you spent on this!
I found the solution, I used fastAPI implementation on uvicorn and somehow the server worked nicely on heroku!!
Thanks again to the community here at aioHTTP!!!
Related
I have a CRA project running which in development mode (yarn start) is slow because of multiple requests being fired and many requests are stale for a long time. In production (deployed on an Apache server) this problem of stale requests holding back future requests is solved.
A difference I can spot is the localhost to api endpoint via a proxy configuration in package.json is running over HTTP/1 and the deployed variant runs over HTTP/2 which allow more requests to be handled simultaneously.
Does this theory of HTTP/1 over 2 makes any sense for my problem?
I can't find a way to allow my localhost to proxy over HTTP/2 to my remote server.
I am having issues setting up a BOSH service for a webchat. As XMPP server I'm using OpenFire and I'm already able to connect to the server using the Pidgin client. What I've done is the following:
First of all I've enabled the proxy using a2enmod proxy proxy_http. Then I went to edit the proxy.conf and added these in the end
ProxyVia On
ProxyErrorOverride On
ProxyPass /http-bind http://localhost:7070/http-bind
ProxyPassReverse /http-bind http://localhost:7070/http-bind
However, when i try to reach http://example.com/http-bind I get the following:
HTTP ERROR: 400
Problem accessing /http-bind/. Reason:
Bad Request
Powered by Jetty://
What am I doing wrong?
No any error in fact.
While you see the result, which measn that all proxy settings of yours are correct, as the http-bind needs to accept the POST(xml format) data as its true request, it is why the openfire server return 404 to you.
I've trouble in connecting to a wss secured socket server via google appengine frontend with managed VM support.
buy default google exposes only port 8080 in docker image google/nodejs-runtime, Even if expose port 8443 in Dockerfile like below i can connect only to http://localhost:8080 not https://localhost:8443
FROM google/nodejs
WORKDIR /app
ADD package.json /app/
RUN npm install
ADD . /app
EXPOSE 8443
CMD []
ENTRYPOINT ["/nodejs/bin/npm", "start"]
Still i can see port 8080 include in the container
"/nodejs/bin/npm start 8443/tcp, 0.0.0.0:8080->8080/tcp
If i log in to my managed vm instance and run the container image with
docker run -d -p 8443:8443 nodejs.default.wss-check:latest
and try
$curl https://localhost:8443
I get curl: (60) SSL certificate problem: unable to get local issuer certificate, It looks like its connecting but i've to use realdomain name
I've created a issue in github aswell https://github.com/GoogleCloudPlatform/appengine-nodejs-quickstart/issues/13, but not that helpful.
Same set up works like a charm in normal compute instance. but it doesn't auto scale.
Any help on this issue will be appreciated.
The reason you can't curl to https on localhost (curl: (60) SSL certificate problem: unable to get local issuer certificate) is because "localhost" is unknown to any CA. You need to run curl -k https://localhost:8443 to get it to ignore the lack of a certificate for localhost.
Looks like currently Google Managed VM supports Websocket connection only on JAVA
Even if you try websocket connection on with nodejs on GMV it defaults to polling transport. if you wanna see this in live you can use set socket transports, deploy to live and look in to console- network and see which transport its using!
socket.set('transports', [
'websocket'
, 'flashsocket'
, 'htmlfile'
, 'xhr-polling'
, 'jsonp-polling'
]);
We have to wait untill google implements websocket support in Managed VM. If anyone get this working on GMV, Please comment here :)
from google.appengine.api import urlfetch
totango_url = "https://sdr.totango.com/pixel.png"
totango_url2 = "https://app.totango.com/images/accounts-users.png"
result = urlfetch.fetch(totango_url, validate_certificate=None )
print result.status_code
In production , request to totango_url logs indicate (with no error_detail) :
DownloadError: Unable to fetch URL: https://sdr.totango.com/pixel.gif
i ran this curl command. works fine from local setup , for both the https totango urls
curl -v "https://sdr.totango.com/pixel.gif"
curl -v "https://app.totango.com/images/accounts-users.png"
The ssl certificates are valid and same for both urls.
using the urlfetch.fetch on both urls also returns 200 from my (local) datastore console.
However , the urlfetch.fetch calls to https://sdr.totango.com/pixel.png fails with the above error
Also , i ran the same code in the google cloud playground tweaking the sample app-engine application and seem to get a 200 response for totango_url2 while it returns a 500 for totango_url. Both have the same ssl certificate , i think.
is there some ip whitelisting /firewall issue that app-engine in production that i need to take care of?
This sounds more like an issue on the remote side. If you're able to fetch that image from one place but not another, that speaks to the remote site doing some sort of filtering, possibly by IP address.
I have Apache2 SSL which is fronting Spring webapp as follows:
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
All works fine... i mean all links ... are correct, and in general webapp works, so the problem is not a matter of an application or SSL..
Except starting/cancelling webflows: they produce http URLs instead of https://
I found one topic here:
forum.springsource.org/showthread.php?70730-Webflow-2-0-and-reverse-proxy
They say it is not a problem of Spring WebFlow...
What is a workaround in this situation?
Providing that all requests to the Tomcat connector are received via SSL terminated at httpd then you can add the following to your connector:
scheme="https" secure="true"
This tells Tomcat to treat the connection as if it was received over an SSL connection direct to Tomcat. This is required when proxying over http since there is no mechanism within http to pass the SSL info to Tomcat. There are ways to pass some of this info via http headers. Look at the SSLValve docs in Tomcat.
Alternatively, using AJP will work since AJP passes SSL information from httpd to Tomcat.