I searched and found this related post, and use it as the basis for this question
Simple C example of doing an HTTP POST and consuming the response
Jerry's code works perfectly, but I have an unusual issue. I have Cloudflare implemented on the destination server, which means that the destination cannot be addressed by IP, it has to be directed to the fully qualified domain URL. I proved this by using the code, but got a return message from Cloudflare informing me that the IP could not be used.
My question is, will C support POST to a URL, or does it have to be to an IP address? If if will accept the domain, what can I do to alter that code ?
I think http POST should be working fine with URL. You can either use domain name or direct ip. both should work.
In your code, try to edit the variable 'host'.
Related
So let me first try to explain what I need and the use case so it will be easy to circle around my request:
We are building a voting system based on Quarkus and have to restrict under certain conditions the voter to be able to vote, e.g. he registered that he lives in France but the request is coming from Zambia.
For that we are thinking about getting the IP address of the request and with the help of ip2location.com, we plan on determining the location of the voter.
The only mention that I saw to get the IP address was in a sample code regarding logging and I have found none to be able to get it from inside my code to be processed (in our case, get the IP, call the ip2location service, match against the database, reject or validate the vote).
So how can I get that IP address from inside an application built with Quarkus?
#Inject HttpServletRequest or #Inject HttpRequest definitely don't work.
Regards,
D.
You can use:
#Context
HttpServerRequest request;
...
request.remoteAddress();
in a JAX-RS resource class.
But even that won't be enough if you are behind a proxy. Im that case you would likely need to the read the X-Forwarded-For HTTP header.
I am trying to implement a REST protocol and have realized in trying to debug that my web server is disallowing the PUT request.
I have tested and confirmed this further by running:
curl -X PUT http://www.mywebserver.com/testpage
Which for my web server gives back a 403 - Forbidden error.
The same happens for DELETE, where as for POST and GET everything is fine.
I am wondering if this is a common issue that those who use REST encounter and what the work-around might be?
Could I make a simple change to an .htaccess file? Or do I need to modify the protocol to set a hidden variable "_method" in the POST query string?
Often web servers will be configured to block anything except GET and POST since
99% of the time they're all that are needed and there have been problems in the
past with applications assuming the requests were one of those two.
You don't say which server it is but, for example, you can tell Apache which
methods to allow with the directive:
eg:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
It sounds like maybe some helpful sysadmin has used this to block non GET/POST
You could try an .htaccess with
<Limit GET POST PUT DELETE>
Allow from all
</Limit>
(I'm not an expert at apache, this may not be exactly correct)
I'm using Nginx as a proxy to filter requests for my AppEngine Java application. GAE's location services (X-AppEngine-country header) works great without the proxy, but now GAE is using the proxy server's IP as client IP, and the X-AppEngine-country header is quite useless - it returns "ZZ" as the country code.
I know that the header is determined by the client IP, as mentioned here:
"X-AppEngine-Country -
Country from which the request originated, as an ISO 3166-1 alpha-2 country code. App Engine determines this code from the client's IP address. "
The problem is that I don't know from what data this header is derived. I used Nginx modules to set the client IP in X-Forwarded-For, Remote_Addr and Http_Client_IP headers, but apparently the X-AppEngine-country header is derived from somewhere else.
How can I provide GAE the client IP so it can retrieve the correct country code from the original IP?
You already provided all the info needed for the answer: "..App Engine determines this code from the client's IP address". So they actually look at an IP from where the connection was made.
Since your proxy sits between the client and AppEngine, AppEngine sees connections coming from proxy IP. No way around it.
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property
I'm working with a third party webservice who requires that all calls to their service are made from whitelisted IP addresses. That is, I must give them IP addresses from which I will be making calls to their service.
Problem is I'm using Google Appengine. Is there any way to get a static IP address when making outgoing http requests from Appengine? Failing that - is there a block of IP addresses that all requests will come from? I could get the entire bloc whitelisted. If this exists, how likely is it to change?
I know I could setup a simple Amazon EC2 instance to use as a proxy (will ask another question for how to do this specifically) but just wanted to make sure there was no other way.
I had the same problem a couple of weeks ago connecting via Urlfetch from Google App Engine to the Stack Exchange API (The team has promptly fixed the problem whitelisting all the GAE IPs).
The range of IP addresses that urlfetch connections may come from, can be found by performing the following DNS lookup:
dig -t TXT _netblocks.google.com #ns1.google.com
Last I checked this wasn't possible. You can get the current IP address dynamically, but it isn't predictable.
Please note: _netblocks.google.com is apparently not accurate. Currently I have noticed that GAE connects from addresses not listed when you dig _netblocks, for example from 8.35.201.166.
This range is not listed in _netblocks, _netblocks2 or _netblocks3.
Current dig output:
ip4:216.239.32.0/19
ip4:64.233.160.0/19
ip4:66.249.80.0/20
ip4:72.14.192.0/18
ip4:209.85.128.0/17
ip4:66.102.0.0/20
ip4:74.125.0.0/16
ip4:64.18.0.0/20
ip4:207.126.144.0/20
ip4:173.194.0.0/16