I would like to know what field within the http packet which was sent by client browser to WEB server can i look to detect whether the request was made from mobile device or from a PC.
My web server is open source which uses C programming language and runs a TCP socket and listens on HTTP port.
Can anyone please let me know.
You need to see for HTTP header called "User-Agent". The value of this will help you determine where the request was made from.
For further details you can check this answer: Auto detect mobile browser (via user-agent?)
Related
I am new to web development. I had a web project with EJS templating. It redirects directly from the server. Using res.redirect() . I want to create a server for web and mobile both.
Question is... When i use res.json() it sends JSON data to client side. Can work for both.
It is possible to use res.redirect() for both. Web and mobile.
Pros and cons of res.rediret and res.json
Please explain. I appreciate your suggestions in adv. Thanks.
It is possible to use res.redirect() for both. Web and mobile.
If you mean can you use res.redirect() as an alternative to res.json() then the answer is NO. res.redirect() is not an alternative to res.json. res.redirect() only sends a code and a URL back to the client, there is no data in the response. You will still need to use res.json or res.send to get the data you need. Every time you use res.redirect() you are sending a response to the client telling them to make a brand new request to another location. You're not sending any real data. The android app will not get any content till you use res.json or res.send. Redirects just tell the client go get the data from somewhere else.
Below are example responses to an android app when the server uses res.json and res.redirect
res.redirect("/user")
//Response to Android app
302 /user
The response above means what you want is located at "/user" so the mobile app will need to make a request to
res.json(user)
//Response to Android app
{
name: "Arpit Yadav",
phone: 555-555
}
res.redirect sends status code 302 (if not specified), and location (route) to browser, after which browser redirects the request to the specified location, whereas res.json sets Content-Type: application/json and sends data to the browser.
Redirection is generally meant for browser only, but, you can use it for mobile. In that case, you have to handle the logic to re-request with updated location received from server that is not recommended.
In nutshell, both have different purpose. res.redirect to move clients to different route and res.json to actually sends the data.
I have a server and an android app. My server want to request a destination but with the IP of the android device that my app is running on. So I need to proxy the requests (relay them) in my app so the destination could see the client's IP but the server. You can see my explanation in the picture:
How can I do this in my app?
Yes this could be done but not just with relays; you also need to port forwarding mechanism in between. Here is how I would try to do this:
Local portforward the requests of the server onto a dedicated port on your android device and then from their call the Destination server via your relay mechanism which could be fulfilled very succicntly by LittleProxy like solution.
I've been creating an app to learn how Android works and just playing around with various features like the sensors, SMS listeners, phone listeners, wifi listeners, etc.
I recently added a bit of code from the Android Volley library to send a request to my website every time it connects to a wifi network (I don't have a cellular data plan).
It sends a GET request to a very sparse text file that returns back:
hello
The odd thing is that after connecting to open public wifi networks, oftentimes the response that the phone gets from this same request will be:
<html>
<title>Redirecting...</title>
<script language="javascript">
document.location.href="http://den-80202-7200.localdomain:8000/index.php?zone=pms&redurl=http://my-personal-server.com/hello
</script>
</html>
Which is really strange to me, as it will return this even the next day, connecting to other networks, connecting to my secured network at home, etc.
And I have no idea what this URL is:
http://den-80202-7200.localdomain:8000
It appears to me, (still learning about how this all works), that my phone is sending my GET request to my website, but somehow my website is returning back this possibly infected response, which, if I was in a browser may harm me. Maybe my website server is infected with something?
Or, my phone has malware that is sending all my requests through this unknown server?
Is that what is going on? How to prevent my phone from keep sending requests through this unknown server? I did a virus scan and it comes up clean. Is there a way to flush the phone's DNS cache or something similar?
While in general it's good to be suspicious about hijacked or modified requests on open wifi networks, in this case it appears to be expected behavior for public wifi networks.
Specifically, many public wifi networks require authentication either for paid access or to accept terms of service. To accomplish this, they will often intercept HTTP requests from unauthenticated clients and return a response which redirects them to a captive portal.
Since .localdomain is not a valid TLD, this URL will not work outside a network without a local DNS entry for it. This appears similar to the use of .local as a reserved TLD for local-network only DNS entries. Again, this is indicative of public wifi networks using .localdomain URLs to redirect to a locally hosted captive portal.
Note also that the redirect URL has the parameter "redurl=http://my-personal-server.com/hello", this specifies the URL that you'll be redirected to after your authenticate. As expected, this was the original URL you requested.
NOTE: As for this showing up on your private wifi networks afterwards, I suspect this is a caching issue. Again, since .localdomain isn't a valid TLD the request to "http://den-80202-7200.localdomain:8000" will fail outside of the public wifi network with support for this specific DNS entry.
Maybe your system is infected with Malware or SpyBots.
Check out below link:
http://www.speedguide.net/port.php?port=8000
A sample mobile application sends POST requests to a HTTP server which we use to process information sent from the mobile application. We parse HTTP headers and the User-Agent header is always seen as "Apache-HttpClient" on all Android devices with different OSes.
If i perform any action from app in android device, it returns the user agent as Apache-HttpClient/UNAVAILABLE (java 1.4)
what's the problem? It doesn't provide me a User Agent string which contains information like OS information and other details.. Has anyone seen similar behavior before?
Apache-HttpClient/UNAVAILABLE (java 1.4)
Is the default User Agent string for the Apache client that your app is using, it is not an error in itself.
This client know's very little about the system that it is running on, which is for the best - it's just a simple one-size-fits-all method for an Android device (which could be a phone, a tablet, a TV or even a car!) to make http requests to the outside world.
User Agent strings are a way for User Agents (read "browsers") to identify themselves.
In the case of an Android App, your App is the browser, so the User agent string is for you to define within your app.
See: Android Generic User Agent (UA)
If you want to send information about the device then you need to collect that information with your app and then send it. Though, if you are collecting that data then you might as well put it in the body of the request rather than HTTP headers anyway.
I wrote a little WS on asp.net, I can open it printing something like
http://46.146.170.225/RouteGen/Service.asmx
in address bar. It's all right, WS works.
But if I print the same address in a browser on the other computer, the page isn't available. How to get access to my web server from other PC? (I need from Android device, but I think it's no difference)
If you started the Web-Service from within Visual Studio then without changing the starup-settings of your project - it's not possible, because VS only starts a local debug web-server that doesn't allow calls from other hosts than localhost.
To allow external IPs to access your web-server, you have to set up the IIS and run your web-service inside it. A firewall could block incoming requests to the IIS but I ran such a service last winter and didn't have to change firewall-settings.
Verify that the website, in IIS, is bound to a public-facing IP address. Right click on your website in IIS, and go to the bindings setting. Then, check the host field. It should have an IP address or domain name that is available publicly.
Verify that your firewall has Port 80 open for incoming traffic