I need simple web server for debugging my application (Arduino web client, curl, etc.).
What is my idea:
I run command like
curl -X POST -H "Content-Type: application/json" \
-H "Accept: application/json" -d '{"address":"192.168.200.3", \
"title":"Abc" }' http://SERVER/xyz
to test webserver running at http://SERVER:80. This webserver write data + all http headers to standard terminal output.
It will be great for testing Arduino with Ethernet shield.
Is there any exiting product (for Linux)? I can write it in Java, but I do not want to reinvent the wheel...
I always use nc (netcat) for this, in a style like:
nc -l -p 8080
It isn't really a "HTTP server" but only a dumb TCP server, but if you're mostly interested in seeing the client request and not necessarily serving back a proper HTTP response then it is good enough.
Related
I'm trying to implement a "dynamic" proxy forward to access localhost from Internet, like Ngrok in pure Java.
This guy does essentially the same thing: https://serveo.net/#intro (but, without a client)
The idea would be to use the SAME port on the server, and make a dynamic proxy for each client, based on a subdomain
The problem is that the default implementation throws error on the second connection .. saying that the port is already open.
org.apache.sshd.common.forward.DefaultForwardingFilter # doBind
Who has an idea of how to implement this?
The advantage of this is that you do not even need a CLIENT like Ngrok for that ... just using normal ssh would be possible.
ssh -R http2:9000:localhost:8002 localhost -p 4440
ssh -R http2:pSERVER:localhost:pLOCAL localhost -p SSHD_PORT
an option I imagined, is to generate the ports dynamically on the server: IGNORING THE 'pSERVER' port, and creating an HttpProxy, to do the redirection for each port. But I find this very inefficient, I believe it would be possible to do only by analyzing the request header and making the redirects for the corresponding channels / connections
After too much headache.
The code is in very low quality, just a proof of concept that can be implemented.
The implemented idea was made by changing sshd-netty, and adding a function to unpack the http request and remove the HOST HEADER (this needs to be improved here).
Only 1 port on the server is used, and it is kind of a reverse proxy for clients ...
I would like the help of the developers to improve the code in question. My knowledge in Netty and Mina is very limited.
Appreciate:
Source: https://github.com/ricardojlrufino/sshd-dyn-tunneling
Testing: Open 2 connections:
ssh -v -R http1:9000:localhost:8001 localhost -p 4440
ssh -v -R http2:9000:localhost:8002 localhost -p 4440
Make requests:
curl -v -H "Host: http1" http1:9000
curl -v -H "Host: http2" http2:9000
Start test servers:
https://github.com/ricardojlrufino/sshd-dyn-tunneling/blob/tunel/src/test/resources/setup_remotes.sh
From what I can tell, the docs all point to the command line interface. We have a java interface that can call a section of our API that is generic that uses JMX for weblogic to configure everything. Our code would be more simple if I kept it similar between the two server types.
What I am finding is that everything I would normally configure in JMX (JDBC, Mail Sessions, JMS, etc) is documented to be called by wildfly on command line.
Is this the normal (recommended) way to configure wildfly so it is ready for your EAR deployment?
One way is to use the native management API - ModelControllerClient - in Java to do your configuration tasks:
ModelControllerClient client = ModelControllerClient.Factory
.create(new ModelControllerClientConfiguration.Builder().setHostName(HOSTNAME).setPort(9990)
.setConnectionTimeout(36000).build());
ModelNode operation = new ModelNode();
operation.get("operation").set("whoami");
operation.get("verbose").set("true");
ModelNode result = client.execute(operation);
System.out.println(result.toString());
Other way is to use the HTTP management API and do the same by this way using any fitting client (e.g. curl):
curl --digest -u admin:passwd.123 -L -D - http://localhost:9990/management \
--header "Content-Type: application/json" \
-d '{"operation":"whoami","verbose":"true","json.pretty":1}'
Im using fabric8 Kubernetes Java Client and Im accessing Kubernetes through HTTP, I followed the example from
fabric8 but I get the following error:
Expected HTTP 100 but received 400 instead, Bad Request.
What do I need to do to upgrade my connection to http/2?
I found out that this has to do with http2, because Kubernetes exec uses SPDY, the problem went away when I upgraded to curl version > 7.36 and installed nghttp2 on the server.
After installing curl I was able to get the response by adding some headers
curl -H "Connection: upgrade" -H "Upgrade: SPDY/3.1" {master url:port/pod/exec}
I can see that the following curl command works remotely:
curl -X GET -d '{"begin":22, "end":33}' http://myRemoteApp.com:8080/publicApi/user/test/data
However as per the docs at http://curl.haxx.se/docs/manpage.html,
-d, --data
(HTTP) Sends the specified data in a POST request to the HTTP server,
in the same way that a browser does when a user has filled in an HTML
form and presses the submit button. This will cause curl to pass the
data to the server using the content-type
application/x-www-form-urlencoded. Compare to -F, --form.
So how is the GET working with curl if we are using -d to post data ?
Also there is no HttpUrlConnection method OR Restlet method to send json in a GET call. Is there ?
According to the curl documentation, -X forces the method word to be a particular value, regardless of whether it results in a sensible request or not. We can run curl with tracing to see what it actually sends in this case:
$ curl -X GET -d '{"begin":22, "end":33}' --trace-ascii - http://localhost:8080/
== Info: About to connect() to localhost port 8080 (#0)
== Info: Trying ::1... == Info: connected
== Info: Connected to localhost (::1) port 8080 (#0)
=> Send header, 238 bytes (0xee)
0000: GET / HTTP/1.1
0010: User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
0050: NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
0084: Host: localhost:8080
009a: Accept: */*
00a7: Content-Length: 22
00bb: Content-Type: application/x-www-form-urlencoded
00ec:
=> Send data, 22 bytes (0x16)
0000: {"begin":22, "end":33}
So this command does in fact cause curl to send a GET request with a message body.
This question has some extensive discussion of using GET with a request body. The answers agree that it's not actually illegal to send a GET request with a message body, but you can't expect the server to pay attention to the body. It seems that the specific server which you're using does handle these requests, whether due to a bug, happy accident, or deliberate design decision.
I have seen many similiar questions but no good answer despite some of them being accepted.
I have registered for C2DM. I received confirmation email. Then I wrote some simple app to register for C2DM. I get the id (tried on emulator and on real device). Then I got the auth token (with curl) for my email that I used for C2DM registration (the same email that I use in app for acquiring the id).
When I try to do the push (also with curl), I get 401 error (like the auth token is wrong).
I read many tutorials and I am running out of ideas.
Let me try it (with curl only):
At first we are applying for the auth token:
curl.exe -v -k https://www.google.com/accounts/ClientLogin -d Email=xyz#gmail.com -d Passwd=secret -d accountType=GOOGLE -d source=your.registered.domain -d service=ac2dm
In the result your are receiving the auth token:
< HTTP/1.1 200 OK
SID=XXX
LSID=XXX
Auth=XXX
* Connection #0 to host www.google.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Please note that the Auth response is in the result with an uppercase first letter: "Auth=XXX"!
Now we are using the result for the next request but with lowercase first letter:
curl.exe -v -k --header "Authorization: GoogleLogin auth=XXX" https://android.apis.google.com/c2dm/send -d "registration_id=XXX" -d "data=helloooo" -d collapse_key=Z
And this works! But you are getting a 401 error, if you are using the auth like in the first response (upper case A in "Auth"):
curl.exe" -v -k --header "Authorization: GoogleLogin Auth=XXX" https://android.apis.google.com/c2dm/send -d "registration_id=XXX" -d "data=helloooo" -d collapse_key=Z
So the "auth" of request 2 is case sensitive. I think this is a pitfall 50% of the users are stepping into. Hope that helps.
Maybe this is the problem?
http://groups.google.com/group/vogella/browse_thread/thread/95865344e6d2c734
Basucally, the "sender" parameter that you specifiy on teh Android device must be the same email address that is registred as the sender (server-side).