Currently i'm using JSTL tag to get the URL from third party API. for this i have added the standard-1.0.6.jar in the classpath. I used tomcat server.
I would like to know how this really works technically. Which HTTP client is used by c:import? whether there is separate http client for JSTL built inside standard.jar, or will it use http client used by tomcat server?
If i need to access the internet to get the same third party API using a internet proxy server, which part of HTTP client i need to modify (in standard.jar for any jstl http client or in tomcat httpclient)?
It's just using the standard Java SE URLConnection class. You can use it in plain Java as follows:
URLConnection connection = new URL("http://stackoverflow.com").openConnection();
InputStream input = connection.getInputStream();
// ...
Or by the URL#openStream() shortcut:
InputStream input = new URL("http://stackoverflow.com").openStream();
// ...
The InputStream contains the HTTP response. Just read/write it to an arbitrary OutputStream the usual way.
See also:
Using java.net.URLConnection to fire and handle HTTP requests
Related
I am writing a basic http proxy using the com.sun.net library that uses HTTP Server and right now my proxy is able to receive the information from the client, but once I have it, how do I pass it on to a different URL (the server) that I specify? I hard coded the client to only connect to my proxys IP so I need to create a new request that uses the same headers and body to pass on to the server.
All I have access to in my handle method is a
HttpExchange t
so that is what I have to use to make the new request.
When I call a web service that sits on a load balancer with jax-ws, it returns
The server sent HTTP status code 302: Moved Temporarily
and then fails, but when I use SoapUI it works fine.
Is there a way that I can configure the service to handle this correctly?
I generated the webservice code using wsimport and make the call as such
NotificationWebService service = new NotificationWebService(wsdlLocation, qName);
NotificationWebServiceSoap serviceSoap = service.getNotificationWebServiceSoap();
String xmlString = serviceSoap.getRSAPublicKeyXMLString();
I'm stuck and I haven't been able to find a solution anywhere so any help would be appreciated.
So after lots of investigation I finally figured out what the problem was. It was all down to redirecting from http to https. From articles I found on the web (can't remember the urls anymore), is that the libraries that the wsdl2java and wsimport stub generators use to do the webservice communication don't allow a http to https redirect follow due to security reasons.
So even though I was generating the stubs from a https wsdl location ie. https://wsdl.location.com?wsdl, when I ran the code to do a webservice call, it was trying to make the call to http://wsdl.location.com which resulted in a redirect request to https://wsdl.location.com, But the http library does not allow that. So it just forwards the 302 http code up as an exception.
Also, there are two web-service urls. One is a testing service which is normal http url and then there is a production server which is over https. So to work around this is all I did is configure the service on the fly to use the end-point I have specified (which is now the https address) by using the BindingProvider class. This also allows me to specify on the fly depending on which environment that is making to call, to use the test url or the production one ie.
NotificationWebService service = new NotificationWebService();
NotificationWebServiceSoap serviceSoap = service.getNotificationWebServiceSoap();
BindingProvider bindingProvider = (BindingProvider) serviceSoap;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://wsdl.location.com");
String xmlString = serviceSoap.getRSAPublicKeyXMLString();
So in short, if anyone encounters this problem. Make sure if the end point you need point to is on https, that you are making a direct https call and not a http call that will ask for an https redirect. You can check this by examining the serviceSoap while debugging. It will say to which url it is making the call.
I didn't look into or go with the option to configure wsdl2java and wsimport to generate the stubs and force the stubs to use the https call so that I could configure multiple url end-points for different environments.
Yes. You didn't say what you're using for the transport, but if it's something like HttpClient you need to set it up to follow redirects. You may need to fiddle with the auto-generated code, or alternatively, perhaps try a higher level abstraction, like Spring Web Services or CXF.
Reason is the redirection issue on web service call control gets transfered from HTTP to HTTPS. Edit your WSDL file you will find the below code:
original code:
soap:address location="http://www.google.com/Services/Services_xyz.asmx"
changed code:
soap:address location="https://www.google.com/Services/Services_xyz.asmx"
Just change the location attribute HTTP to HTTPS and generate the new stub using the changed WSDL file location.
I am developing a software which will be communicating with a server using HTTP (but it is not a web browser). Since the server part is not ready yet, I would like to debug my client software by sending HTTP messages to it. I know that I can send HTTP requests using Curl. But I am not sure if that is sufficient here.
I'm imagining an environment where I send a request from my application, check that it is correct using Wireshark and then reply to the request using some software. Using Curl, I think I would have open a listening port..?
I'd use a simple node.js server for this. You can write your own HTTP server in a few lines of code an simulate various return codes, response headers or response entities easily: http://nodejs.org/
PS: There are proxies that simply print out the HTTP messages. This might be helpful for you too, because you don't have to deal with WireShark anymore just for HTTP-level logging.
You can't do that with cURL. It is an http client, not a server.
The simplest way to do this is to actually implement a mock server application that just returns a static (i.e. hardcoded) message every time. You can do this using any server-side language you like (php, python, ruby, ...), or, you can even do it without a server side language, using just static files served by a webserver such as apache or nginx.
For example, if the server part (the API) would respond to /articles.json with something relevant (a JSON object containing some articles), you could put a file named articles.json that contains some hand-written data in your server's root. Then, your application would think it's calling an API when it's actually just downloading a static file.
You can use firebug addon of firefox browser to see content of HTTP request/response.
It does't require any server (but of course, if you dont have server which process requests from browser and send responses to browser, you 'll always see response "unable to connect").
If you still need to mock response, you can create simple server which is able to respond with mock responses, for example java servlet at tomcat server, with code like this:
public class MyMockServlet extends HttpServlet {
..
private String mockHeaders = "...";
private String mockResponse = "my response";
public void service(HttpRequest request, HttpResponse response){
setHeaderAndBodyInResponse(response);//your method
}
}
I want to create a small java application to copy some wiki content from one server to another. The API is based on the XML-RPC.
Basically I have three methods, login, getPage and putPage. I use Apache HttpClient 3.x and managed to use login to login successfully and getPage to get a page from the old wiki correctly.
Authentication is handled with cookies: I log into the new wiki and some cookies are set on the corresponding httpclient. The doku tells me that one of those cookies is used for authentification.
Then I execute putPage with another POST method on the same httpclient and the server responds with a authentication failure message.
The code sequence goes like this (very reduced):
HttpClient client = new HttpClient();
PostMethod postLogin = createNewPostMethod("login", "user", "pw");
client.executeMethod(postLogin);
// Now I'm logged in and the client definitly has stored the cookies
PostMethod postPutPage = createNewPostMethod("putPage", getPage());
client.executeMethod(postPutPage); // the server won't let me put the page
Should it work like that or do I have to add the cookies manually to the second post method and, if yes, how?
Edit / Solution
With the help of the answers to this question I was able to identify and solve the problem, which was outside of the usage of httpclient. At the end it was a configuration issue on the target wiki side. The answers here helped me to ask the right questions in another forum.
Cookies are handled by HTTPClient by default. You shouldn't have to do anything to have cookies work properly.
Source:
http://www.innovation.ch/java/HTTPClient/getting_started.html#cookies
Edit for Apache HTTP Client:
Apache HTTP Client behaves the same :-)
Here is the source:
http://hc.apache.org/httpclient-3.x/cookies.html
You can set manually cookies with HTTP Client but it will handle correctly cookies created during your connection.
HttpClient supports automatic management of cookies, including allowing the server to set cookies and automatically return them to the server when required. It is also possible to manually set cookies to be sent to the server.
Resources :
Apache HttpClient - cookies
I have historically used this when I wanted to accept cookies with HttpClient
postPutPage.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
How would you create a server-side java applet?
If I understand correctly, you are looking for Servlets. Read the linked documentation.
Otherwise, your question doesn't make sense - the server is processing multiple requests, without any GUI, and applets are GUI.
If you just want java code that runs on the server, you probably do want Servlets. Or perhaps JSP, if you're just looking for something to do simple processing.
A Java applet on the client side does not necessarily require a Java webserver on the server side. Since the only communication protocol you'd like to use is HTTP which is universal, any HTTP server would suffice. You can use a "plain vanilla" webserver like Apache HTTPD with PHP. You can also use a Java Servletcontainer like Apache Tomcat which supports JSP/Servlet. You can also use a C#/.NET webserver like IIS which supports ASP. Just make use the capabilities of the webserver which you're currently already using to serve the webpage with the applet.
All you basically need to do in the Applet is to fire and process HTTP requests. You can do that with java.net.URLConnection (mini tutorial here) or with the more convenienced Apache HttpComponents Client (tutorial here). You can use Applet#getCodeBase() to obtain the context URL where the applet is served from.
URL url = new URL(getCodeBase(), "script.php"); // PHP code
// or
URL url = new URL(getCodeBase(), "servletUrl"); // Servlet code
// or
URL url = new URL(getCodeBase(), "script.asp"); // ASP code
In the server side you just return response in whatever format you like the usual way. A plain vanilla String or a more easy processable JSON or XML format. All mentioned languages provides facilities/libraries to encode/decode the data in JSON/XML formats.
As to sending parameters from Applet to the server side, just pass HTTP request parameters along as a query string in the request URL (HTTP GET) or in request body (HTTP POST). In PHP you can gather them by $_GET and $_POST and in Java Servlet by request.getParameter().
As to returning the data from the server side, in PHP you just use echo to write the response. In Java Servlet you just write to response.getWriter() and in ASP I actually have no idea, but you should got the picture now. In the Applet you should then read and process the response accordingly. See the aforementioned tutorial links how to do that.