String url = "http://script.google.com/macros/s/" + GOOGLE_SCRIPT_ID + "/exec?" + data;
Serial.print(url);
HTTPClient https;
https.begin(url);
delay(200);
int httpsCode = https.GET();
I want to send the readed data from a MRFC555, tag and name to store it on google Sheet, but i'm facing some troubles with http request
when i use https the board reboot and when i use http i got "-1
[HTTP] GET... failed, error: connection refused"
Related
I would like to make http request from my lua filter to an external server.
According to Envoy documentation, http call can be done using request_handle:httpCall:
function envoy_on_request(request_handle)
-- Make an HTTP call to an upstream host with the following headers, body, and timeout.
local headers, body = request_handle:httpCall(
"lua_cluster",
{
[":method"] = "POST",
[":path"] = "/",
[":authority"] = "lua_cluster"
},
"hello world",
5000)
I have created a cluster called lua_cluster in my envoy.yaml file as needed, but the request doesn't reach my server and I'm getting 400 response.
Possible solution??
When changing the authority header from [":authority"] = "lua_cluster" to [":authority"] = "<cluster's url hostname>", the request arrived to the server and I got 200 response from the server. Can someone explain this? Is it a valid thing to do?
When use an AWS ELB (Elastic Load Balancer) with HTTPS listener that forward the request to the presto cluster (0.193) behind that runs on HTTP, Java client that uses presto-jdbc (0.213) fails to execute select query due to "plain HTTP request was sent to HTTPS port" error.
Exception in thread "main" java.sql.SQLException: Error executing query
at com.facebook.presto.jdbc.PrestoStatement.internalExecute(PrestoStatement.java:274)
at com.facebook.presto.jdbc.PrestoStatement.execute(PrestoStatement.java:227)
at com.facebook.presto.jdbc.PrestoStatement.executeQuery(PrestoStatement.java:76)
at com.DpTool.executeJdbcQuerySsl(DpTool.java:332)
at com.DpTool.prestoJdbcSsl(DpTool.java:315)
at com.DpTool.main(DpTool.java:520)
Caused by: java.lang.RuntimeException: Error fetching next at http://cluster-elb.mydomain:8443/v1/statement/20181120_215602_00038_57ryf/1 returned an invalid response: JsonResponse{statusCode=400, statusMessage=Bad Request, headers={connection=[close], content-length=[236], content-type=[text/html], date=[Tue, 20 Nov 2018 21:56:02 GMT], server=[awselb/2.0]}, hasValue=false} [Error: <html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>
]
at com.facebook.presto.jdbc.internal.client.StatementClientV1.requestFailedException(StatementClientV1.java:436)
at com.facebook.presto.jdbc.internal.client.StatementClientV1.advance(StatementClientV1.java:383)
at com.facebook.presto.jdbc.PrestoResultSet.getColumns(PrestoResultSet.java:1742)
at com.facebook.presto.jdbc.PrestoResultSet.<init>(PrestoResultSet.java:119)
at com.facebook.presto.jdbc.PrestoStatement.internalExecute(PrestoStatement.java:249)
... 5 more
It appears that StatementClientV1.advance code try to visit "http://cluster-elb.mydomain:8443/..." which is the ELB address except it should be "https" instead of "http" prefix. The same client code works fine when execute query directly to another HTTPS presto cluster (no ELB). Here is the client Java code. url is "cluster-elb.mydomain:8443"
Properties properties = new Properties();
properties.setProperty("SSL", "true");
Connection conn = DriverManager.getConnection(url, properties);
Statement stmt = conn.createStatement();
String query = "select cluster, query_text from mytable where ds='2018-10-20' limit 10";
ResultSet rs = stmt.executeQuery(query);
Why the presto-jdbc client code is confused and how to make the query work?
This should work in newer versions of Presto. Try it with 0.213.
The problem is due to https://github.com/prestodb/presto/issues/8232 where the nextUri field in QueryStatusInfo is incorrectly set as http instead of https by presto server (when client talk to presto through elb or proxy).
I’m using jersey-client v1.18.1
I need to make 2 sequential requests where the 1st request has an InputStream and then must pass that same InputStream along to the 2nd request (eg. sort of like a proxy). The 2nd request will then write the InputStream to disk and send back to the 1st request the fully qualified path to the location on disk where the 2nd request wrote the file.
The following code-snippet outlines what I have tried, but cannot get to work properly. I’m currently receiving the error:
"com.sun.jersey.api.client.ClientHandlerException: A message body writer for Java type, class org.seleniumhq.jetty9.server.HttpInputOverHTTP, and MIME media type, application/octet-stream, was not found”
I believe I have all the proper Maven dependencies in my project for the MIME and message body writers.
1st Request originating on Host 1 going to Host 2
Client client = Client.create();
client.resource(uri_for_request_1)
client.path(“request_1_servlet");
client.queryParam(“uri_for_request_2", uri_for_request_2);
client.queryParam("targetFilename", targetFilename);
ClientResponse response = client.accept(MediaType.APPLICATION_JSON).entity(inputStream).post(ClientResponse.class);
2nd Request originating on Host 2 going to Host 3
Client client = Client.create();
client.resource(request.getParamater(“uri_for_request_2"))
client.path(“request_2_servlet");
client.queryParam("targetFilename", request.getParamater(“targetFilename");
ClientResponse response = client.accept(MediaType.APPLICATION_JSON).entity(request.getInputStream()).post(ClientResponse.class);
Host 3
Writes InputStream to file and sends back to Host 2 fully qualified path.
Host 2
Sends back to Host 1 fully qualified path.
Variations I’ve tried on post calls:
client.accept(MediaType.APPLICATION_JSON).type(MediaType.APPLICATION_OCTET_STREAM).entity(inputStream).post(ClientResponse.class);
client.accept(MediaType.APPLICATION_JSON).type(MediaType.APPLICATION_OCTET_STREAM).post(ClientResponse.class, inputStream);
I can confirm the 1st request is being made on Host 1 and reaches Host 2. It is the 2nd request on Host 2 that fails during the post() call.
I'm using Express.IO and This iOS Client trying to create a basic socket example but I can't seem to be able to connect.
I tried everything I could possibly find on google but everytime my client tries connecting I get the following error:
2013-08-12 14:48:42.628 SocketIOTest[59835:c07] ERROR: handshake failed ... Could not connect to the server.
2013-08-12 14:48:42.628 SocketIOTest[59835:c07] OnError: Error Domain=NSURLErrorDomain Code=-1004 "Could not connect to the server." UserInfo=0x7594570 {NSErrorFailingURLStringKey=http://localhost:7076/socket.io/1/?t=16807, NSErrorFailingURLKey=http://localhost:7076/socket.io/1/?t=16807, NSLocalizedDescription=Could not connect to the server., NSUnderlyingError=0x10967bb0 "Could not connect to the server."}
When I go to http://localhost:7076/socket.io/1/?t=16807 in my browser I get this response:
ttIwyz7Tw6uFjp00WceI:60:60:websocket,htmlfile,xhr-polling,jsonp-polling
But for some reason when checking with header tools, it actually does return an HTTP 500 error. I'm really not sure why.
Here's my Node code:
#!/usr/bin/env node
var express = require('express.io');
var app = express().http().io();
var redisStore = require('connect-redis')(express);
app.use(express.cookieParser());
app.use(express.session({
store: new redisStore({
host: '192.168.33.10',
port: 6386
}),
secret: 'A>mVt*Cx87Kq^9:3}am$q67JYtGGAl'
})) ;
app.use(function(err, req, res, next){
response.header('Access-Control-Allow-Origin', '*');
response.header('Access-Control-Allow-Methods', 'POST, GET, PUT, DELETE, OPTIONS');
response.header('Access-Control-Allow-Credentials', 'true');
response.header('Access-Control-Allow-Headers', 'Content-Type, Accept, Origin, Cookie');
next();
});
app.set( 'origins', '*' );
app.io.on('connection', function (socket) {
console.log("connection");
socket.emit('news', { hello: 'world' });
});
app.listen(7076);
console.log('App API Server is listening on port 7076');
Would appreciate any help on this.
it seems that you are referring to localhost: NSErrorFailingURLStringKey=http://localhost:7076/socket.io/1/?t=16807 in your IOS client, while the node.js server is running on some external Linux box.
Try connecting to the server instead.
I'm trying to find out if a play 2 (with scala) app is running on http or https
I tried with routes.Application.index.absoluteURL(request), like this
def chatUri(username: String)(implicit request: RequestHeader): String = {
val uri = routes.Application.index.absoluteURL(request)
but I get the following error:
/home/sas/tmp/websocket-chat/app/controllers/Application.scala:51: overloaded method value absoluteURL with alternatives:
[error] (secure: Boolean)(implicit request: play.api.mvc.RequestHeader)java.lang.String <and>
[error] (play.mvc.Http.Request)java.lang.String
[error] cannot be applied to (play.api.mvc.RequestHeader)
[error] val rootUri = Uri(routes.Application.index.absoluteURL(request))
I tried to transform the RequestHeader into a Request, but I get the following error
val rootUri = Uri(routes.Application.index.absoluteURL(request.asInstanceOf[Request[Any]]))
(secure: Boolean)(implicit request: play.api.mvc.RequestHeader)java.lang.String <and>
[error] (play.mvc.Http.Request)java.lang.String
[error] cannot be applied to (play.api.mvc.Request[Any])
[error] val rootUri = Uri(routes.Application.index.absoluteURL(request.asInstanceOf[Request[Any]]))
Any idea how can I achieve it?
Must say I'm surprised about problems with getting absolute url in Scala, AFAIR in Java it works well, anyway... I doubt if it will help you to determine the protocol (edit: as #MariusSoutier wrote)
As there's no built-in support for SSL in Play 2 most probably you are using (or you should use) some HTTP server on front of your application, let's say Apache. There are some samples and posts describing the proccess:
Take a look at topic: How to config PlayFramework2 to support SSL? Nasir gives there a sample of configuring the Apache as a proxy for Play
There's also nice description of configuring Apache as a proxy (warning the posts describes the Play 1.x, however Apache part will be the same)
Finally you need to to set the proper headers which will be forwarded to your app
so after setting the headers (as showed in point 3) you'll be able to check it in your controller:
def index = Action { request =>
val proto = request.headers("X-FORWARDED-PROTO")
Ok("Got request [" + request + "] with schema: " + proto )
}
or the same in Java controller:
public static Result index() {
String proto = request().getHeader("X-FORWARDED-PROTO");
return ok("Got request [" + request() + "] with schema: " + proto);
}
First off, by creating an absolute URL, you cannot find out if the app is running on http or https - take a look at the method signature:
def absoluteURL (secure: Boolean = false)(implicit request: RequestHeader): String
That's right, you have to tell this method whether or not you want secure.
I think this is because Play was designed to working behind a reverse proxy which makes it transparent to use encrypted requests. That means Play shouldn't have to care about this. absoluteURL can only enforce https URLs, for example to make sure a login page uses https.
Depending on your reverse proxy, you can set a custom http header that tells you what is used. RequestHeader doesn't have the information.