I'm creating a program that wants to show statistics.
For that I decided to use websockets and http. Websockets because it requires no polling but allows my server to push any changes (I'm open for suggestions for different solutions) so quick updates. For websockets I use the websocket++ library and for http I use libmicrohttpd.
The program runs on Unix/Linux systems.
Now using websocket++ creating the websockets is simple. I let the user decide on a portnumber and that's that. Same thing for http using libmicrohttpd.
The problem now is, how can I point from html to that websocket service?
I only know a portnumber (that listens on all network interfaces; it binds to 0.0.0.0) and not a hostname. I tried http://:8001/ (so without any hostname, or ip address) but at least firefox doesn't take that.
So how can I resolve that?
I could in theory let websocket++ do the http handling but that doesn't work for binary files like images and it also does not let you process HEAD-requests.
I only know a portnumber (that listens on all network interfaces; it binds to 0.0.0.0) and not a hostname. I tried http://:8001/ (so without any hostname, or ip address) but at least firefox doesn't take that.
Thats not possible to let a webbrowser search for a specified webpage at a specified port, because you have more than million webserver addresses (you cannot not know at all) to search for a open port.
So the only very solution would be to provide an url in the html you mentioned above a script can use to connect to your service.
If you want to bind to localhost (127.0.0.1): http://localhost:8001/ or http://127.0.0.1:8001/
Found the solution:
An http-request has (usually - tried with chrome & firefox) an "Host:"-header. E.g.:
GET / HTTP/1.1
Host: keetweej.vanheusden.com:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
So what I do now is cut the hostname from the Host-record and add the portnumber of the websockets to it.
This works!
Related
I want to open any arbitrary TCP socket on a server, but it's behind a proxy and I can only use a port that is intended for HTTP hosting only. Simply put, what is the most transparent way to wrap such a socket into an HTTP connection? Preferably I would call a *nix program through a shell script in the server that would take care of translating the requests.
I apologize if this was answered before, but I am struggling to find and understand anything.
I ended up going with Chisel, which provides a single binary for both servers and clients, with features like authentication and reverse port forwarding. For instance:
chisel server
will run an HTTP server in $PORT or 8080, and
chisel client server.com 4567:123
connects to server.com and maps the remote port 123 into the local port 4567.
Other solutions are still welcome, particularly if they involve more transparency, frequently preinstalled tools like netcat, and if they also provide support for other protocols like UDP.
Let's say I have this DNS entry: mysite.sample. I am developing, and have a copy of my website running locally in http://localhost:8080. I want this website to be reachable using the (fake) DNS: http://mysite.sample, without being forced to remember in what port this site is running. I can setup /etc/hosts and nginx to do proxing for that, but ... Is there an easier way?
Can I somehow setup a simple DNS entry using /etc/hosts and/or dnsmasq where also a non-standard port (something different than :80/:443) is specified? Without the need to provide extra configuration for nginx?
Or phrased in a simpler way: Is it possible to provide port mappings for dns entries in /etc/hosts or dnsmasq?
DNS has nothing to do with the TCP port. DNS is there to resolv names (e.g. mysite.sample) into IP addresses - kind of like a phone book.
So it's a clear "NO". However, there's another solution and I try to explain it.
When you enter http://mysite.sample:8080 in your browser URL bar, your client (e.g. browser) will first try to resolve mysite.sample (via OS calls) to an IP address. This is where DNS kicks in, as DNS is your name resolver. If that happened, the job of DNS is finished and the browser continues.
This is where the "magic" in HTTP happens. The browser is connecting to the resolved IP address and the desired port (by default 80 for http and 443 for https), is waiting for the connection to be accepted and is then sending the following headers:
GET <resource> HTTP/1.1
Host: mysite.sample:8080
Now the server reads those headers and acts accordingly. Most modern web servers have something called "virtual hosts" (i.e. Apache) or "sites" (i.e. nginx). You can configure multiple vhosts/sites - one for each domain. The web server will then provide the site matching the requested host (which is retreived by the browser from the URL bar and passed to the server via Host HTTP header). This is pure HTTP and has nothing to do with TCP.
If you can't change the port of your origin service (in your case 8080), you might want to setup a new web server in front of your service. This is also called reverse proxy. I recommend reading the NGINX Reverse Proxy docs, but you can also use Apache or any other modern web server.
For nginx, just setup a new site and redirect it to your service:
location mysite.example {
proxy_pass http://127.0.0.1:8080;
}
There is a mechanism in DNS for discovering the ports that a service uses, it is called the Service Record (SRV) which has the form
_service._proto.name. TTL class SRV priority weight port target.
However, to make use of this record you would need to have an application that referenced that record prior to making the call. As Dominique has said, this is not the way HTTP works.
I have written a previous answer that explains some of the background to this, and why HTTP isn't in the standard. (the article discusses WS, but the underlying discussion suggested adding this to the HTTP protocol directly)
Edited to add -
There was actually a draft IETF document exploring an official way to do this, but it never made it past draft stage.
This document specifies a new URI scheme called http+srv which uses a DNS SRV lookup to locate a HTTP server.
There is an specific SO answer here which points to an interesting post here
I am trying to connect GPRS GSM A6 to arduino. Everything works fine, but there is a slight problem.
And its that AT+CIPSTART only accepts IP or domain name.
For example this,
AT+CIPSTART="TCP", "xxx.xx.x.xxx", 80
works fine, Or this,
AT+CIPSTART="TCP", "www.google.com", 80
also works fine, but what I am looking for is something like this.
AT+CIPSTART="TCP", "xxx.xx.x.xxx/trackerCode/", 80
That is I want to specify directory along with the ip. But it does not allow me to do this and returns a +CME Error.
Is there a way to do this?
The only way would be direct support in your GPRS module firmware. So start with available AT commands with something like HTTP in it.
If there is none, you have to send HTTP request over TCP connection openned by examples 1 or 2. How the HTTP protocol looks like is defined in RFC 2612. Request name, path and http version on the first line are mandatory, few more headers might be needed (for the server with virtual domains it'll be Host header)
And line endings must be "\r\n"
Suppose I am logged in and connected to a website in firefox (or any other browser) now I can make download requests in the browser. Suppose I want to use wget or curl using the connection of firefox. Is there a way to use firefox as a systemwide proxy for port 443 and 80? Here is a usage scenario: This would be interesting for a download manager, if the requests are proxied and made by the browser, all the credentials stored in the browser could be used.
So the browser would receive the request on port 443 and replicate it or forward it. Proxy and forwarding are probably not the right words in this context.
I am not aware of any feature of Firefox (or any other mainstream browser) that allows to really use it as some kind of proxy, sorry.
You cannot somehow "use the connection firefox already has", since there is no permanent connection between client and server in an http communication. http is a stateless protocol without some socket permanently kept open. Instead each http request is sent separately, each time a new socket is opened.
However something similar might be "half possible" using a crude workaround:
What you can try however is to simply start a new instance of the browser for each request you want to do. In reality this does not start a new instance, but reuses an already existing instance and typically opens a new tab in there. That way you can "remote control" your already started browser in a primitive way and do downloads, if and only if the url you specify will result in a download. However that all depends on the browser settings, so for example downloads will be stored in files in your local file system where you have to read the payload from again.
This all is not really efficient and convenient which is why it probably does not make much sense. Instead you should create a simple script for such communication. The effort for that is not that high.
When I use display filter for HTTP it shows only HTTP packets when HTTP message is on standard port i.e. on port 80. But, when message is not using standard port, then display filter not works for HTTP and I need to filter for TCP and then need to find out HTTP packets manually.
I want to know why this happen? Is it standard behavior or I am doing (or expecting) it wrongly.
Thanks.
I had to enable the HTTP protocol by doing the following:
"Analyze -> Enabled Protocols"
This solution was for version 1.12.2 (and disabled by default in
version 2.0.2) but should work for any variant of version 1 and 2.
If you have HTTP not on its usual port, you can use the "Analyze -> Decode As" tool in Wireshark to tell it to treat all traffic on this port as a certain protocol.
The well-known port for HTTP is port 80. If you're looking at traffic on a different port Wireshark would normally expect traffic to be in the form for whatever service normally uses that port (if any). It has no way to know that traffic on, say, port 1080 is actually HTTP. This is not a bug, but a limitation of the way you are trying to use TCP
I am using version 1.10.2 and it will classify any port as HTTP as long as it sees HTTP data in it.