Facing a problem with protocols, please find the below code snippet.
If rquestedUrl starts with https, getResponse.getStatusLine().getStatusCode() is returning 200 whereas if the same rquestedUrl starts with http, getResponse.getStatusLine().getStatusCode() is returning 404.
But if I hit through browser I am able to access the requested file in both cases. Could you please let me know what could be the possible problems. (It is used as a filter before calling Orbeon, this is on the process of implementing WSSO.)
System.setProperty("javax.net.ssl.trustStore", "path_to_JKSFile");
System.setProperty("javax.net.ssl.trustStoreType","JKS");
System.setProperty("javax.net.ssl.trustStorePassword","password");
String rquestedUrl = "http://bigminds.web.mindblow.com/project/project1/views/files/Home.xhtml";
HttpClient client = HttpClients.createDefault();
HttpGet get = new HttpGet(rquestedUrl);
get.addHeader("Cookie", "somevalues");
get.addHeader("Host", "bigminds.mindblow.com:14325");
HttpResponse getResponse = client.execute(get);
It's likely that the endpoint you are hitting does not accept http requests, all requests must be though https. So there isn't anything wrong with your code, it's just not set up to properly integrate with the site you have there. Looking at the code it looks like you may need to have some type of session (ie: need to login) with the webserver to get the data you want.
Related
I was trying to write a simple script to check if a website has a ssl certificate or not. I came across some tutorials that suggested to use the requests.get() function with the verify parameter set as to be True but whenever I try to target any website that does not have a SSL certificate the program is not showing any error. The link I am trying to test it on is : http://dtdev.atwebpages.com/
and the code is
import requests
response = requests.get("http://dtdev.atwebpages.com/", verify = True)
print(response.text)
verify is for checking whether an https certificate is valid or not. So your use-case (i.e. visiting an http endpoint) doesn't apply here as there are no certificates to validate.
If you want to check whether or not a website supports https you could just try to access its https endpoint and see whether or not you get an error. For example:
from requests.exceptions import ConnectionError
try:
response = requests.head("https://dtdev.atwebpages.com/")
except ConnectionError:
print("Figure out why we couldn't connect")
In addition:
You also just try to access the http endpoint and see whether or not your connection got upgraded. Like here.
Say for example I'm try to make a GET Request to www.testjson.com/json, However the response is retrieved from a different domain URL e.g. www.testjson.com/confirmJson.
Does Spring mvc support this, specifically restTemplate.exchange functionality.
I am currently doing this sort of thing, but I am getting an 500 status code (internal server error) and have no way of finding out what exactly is causing the error.
So can RestTemplate actually manage the redirect and provide the necessary JSON response or does it actually wait for the response from the url you provide hence the reason for getting the 500 internal server error?
It is possible to let a RestTemplate automatically follow a redirect.
The server must respond with a Http 3xx and the location header set.
The RestTemplate 'understands' this response and issues a new GET request to the returned location.
This should work with default spring configuration.
See also follow-302-redirect-using-spring-resttemplate
I'm using Apache HttpClient 4.3.1 and I'm trying to integrate etag validation cache.
I've tried to "drop in" httpclient-cache CachingHttpClientBuilder instead of my usual HttpClientBuilder using instructions in here, but that didn't seem to do any good. While tracing the execution, it seems like a response that has "etag" header (weak etag) isn't considered cache-able - and so isn't retained for the next cycle.
Has anyone managed to use etag validation based cache with Apache HttpClient? I'm also open for alternative implementations.
Notes:
The server returns the first request with a weak etag header (W/"1234"). If the second request to the same URL has "If-None-Match=1234", the server returns 304. This is checked and working.
The server does not send any other cache header (expires, etc).
The whole setup works wonderfully when using a modern browser.
Whether a response is considered as cacheable or not is decided in
ResponseCachingPolicy#isResponseCacheable(org.apache.http.HttpRequest, org.apache.http.HttpResponse)
which checks for some headers using
ResponseCachingPolicy#isExplicitlyCacheable
when
header 'Expires' is set or the header 'Cache-Control:' has one of the values "max-age" "s-maxage" "must-revalidate" "proxy-revalidate" or "public" the response is considered cacheable.
For us, it worked to add "Cache-Control: 'must-revalidate' to the response on the server, along with the 'Etag' header.
With this settings the apache http client
stores the response of the first request in the cache
on the second request, sends a request to the server and if this responds with a HttpStatus 304 (Not Modified) returns a HttpStatus 200 (ok) and the original content to the caller
That is how it should be.
We are using release 4.5.2 of apache http client cache.
I have a frontend in AngularJs and a playframework 2 Scala backend. Looking at this to add CORs to the backend - I have two endpoints a GET and POST
GET /api/question/:id controllers.Questions.getQuestion(id: String)
POST /api/question/:id controllers.Questions.postQuestion(id: String)
This solution provided in the other response works for the GET but not for the POST
def getQuestion(key:String) = CorsAction{
....
}
def postQuestion(key:String) = CorsAction(parse.json){
req =>
........
}
What I understood is that the CORsAction (which extends ActionBuilder) can also accept methods which a bodyparser and thus should essentially work for POST requests as well.
This is what I see in the browser console when i hit POST from my front end.
OPTIONS http://localhost:9000/api/question/abc123 No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3001' is therefore not allowed access. angular.js:7997
XMLHttpRequest cannot load http://localhost:9000/api/question/abc123. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3001' is therefore not allowed access.
So I'm not sure the exact problem but adding the following to the routes
fixed the problem
OPTIONS /api/question/:id controllers.Application.preflight(id)
Where the preflight endpont just returns Ok with the CORs headers. But I would have thought that the CorsAction was supposed to take care of this. Anyways, moving on.
The answer to this little question will clear everything up for me.
If have a form tag that has a Get method and an action of some random script.
When I hit the submit button on the page, the Get Method is sent to HTTP and HTTP is what appends the query string to the url, the HTTP then returns a 20X status if the response is good and a 40X is a bad response? And our action goes to our webserver to run the script?
HTTP is transport and HTML is content. The Form submit calls a GET or POST request on the server depending on the action defined for the HTML form. The Form's arguments are appended by the Browser's form logic to the HTTP request, depending whehter GET or POST is used, they are attached to the request URL or put into the request body.
Then the request is handled on the server and the result is returned by the server logic (which can be a CGI, some perl script, a J2EE application etc.).
The server seponds with a HTTP status code (where everything below 300 is a success, and everything above 399 is an error - see here:HTTP staus codes ).
You are sending your form's data via HTTP using the "get" request. HTTP is a protocol and not a server. Your request is handled by a server who knows how to handle the HTTP protocol, eg. Apache.
The server processes the data and sends back a response. As you mention there are different kind of responses. 404 is best known (document not found).
The script is not run on the server, it is run on the client (the browser).
HTML is the markup code that describes the structure of the page. Browsers interpet the HTML code they receive and construct your page from it. Check here for more details: Wikipedia: HTML
The HTTP is the protocol used by the browser to talk to the server. Check this for more details: Wikipedia again: HTTP