I am trying to upload a file (and additional fields) using single REST POST request. This request has to be processed asynchronous and form has to be submitted using multipart-form content type (because beside file I am sending few other text fields with certain metadata).
I tried with Apache's org.apache.http.impl.nio.client.CloseableHttpAsyncClient but until now I didn't succeed (when request arrives on the server, fields from the form are not presented). When I do the same using org.apache.commons.httpclient.HttpClient request is processed without problems, so the issue is not on the server side.
Does anybody know how this async 'multipart-form' request could be made? If not possible with CloseableHttpAsyncClient, do you have some other library to suggest?
Thanks in advance...
I just want to give an update. I did some investigation and was able to fulfill my requirements with AsyncHttpClient (AHC)
It works very fast and is based on Netty Framework and NIO Java API.
Related
I'm using java and I'm looking for solution to get respond from website.
The problem is i need to create a handshake with server for about 30 sec and then send header and body to finish request.This also a multipart/formdata POST method.
can anyone suggest me where to find tutorial or some example of code?
Thank you.
You can surely work lower-level (TCP-level) blocking-style as in http://examples.javacodegeeks.com/core-java/net/socket/send-http-post-request-with-socket/
I'm confident there should be a way to do that in Netty, you could try having a look at How to send a request with POST parameters in Netty?.
I couldn't find other Java libraries that would allow you to wait before sending headers, but many (including JDK's URLConnection) will allow you to pre-configure headers and then stream the body.
My task is to load web site in WebView over HTTPS with unsupported by vanilla Android TLS cipher.
Right now as proof of concept I have implemented apache http client capable of doing http requests to such resources.
What is the best approach to make WebView use my custom client implementation to do all network requests?
Actually, the accepted answer is wrong. You do not get full information; what's missing are request bodies.
So you can implement GET or HEAD requests just fine, but POST requests are trickier.
I haven't seen a good solution for that yet. One I've come across uses JavaScript inserted into the page to collect the POST data, hand it to Java via a binding https://developer.android.com/guide/webapps/webview.html#BindingJavaScript and then performs the request in Java.
Unfortunately, the WebView will try to perform the same request again, so you need to add more hackery to make it work.
Since Android 5.0 (API 21+) you can use WebViewClient.shouldInterceptRequest(WebView, WebResourceRequest) to intercept web requests with full information and perform them with custom HTTP client.
Thanks #Stan for the tip.
I'm a little unfamiliar both with the Servlet API and Apache Http Components.
I need to handle an incoming POST request with unknown data (although probably the result of a form submission) using HttpServlet.doPost() which I've implemented, and request the same posted information from another URL, effectively acting as a relay for the HTTP POST. I then need to convert the response to a String (it will be text/html) and process it further before returning it to the web browser that requested it from me.
Due to my unfamiliarity with these libraries, its not clear to me how to handle issues like the content-type of the posted data, and also avoiding any problems due to neglecting to release resources.
Can anyone provide any pointers on this?
You should start by having a look at HttpClient class from apache API.
It will handle both get and posts as needed and later you could feel its request with the data you receive in your own servlet.
I'm doing a project on java download manager.i want to download a single file(which is in some website) with multiple connections(just like download Managers do,example-IDM).Is this possible in java ?.if yes please help me how can i implement that.if you people have any sample code then please post.Thank you in Advance..Have a Rocking Future.
Here are a couple of hints. No code though.
A multi-connection download manager relies on the support for the Accept-Ranges header in the HTTP 1.1 specification. Servers would use this header to indicate that they support sending of partial responses to the client.
HTTP clients use the Range header in the request to obtain partial responses. All partial responses will carry a Content-Range header.
A multi-connection download manager would make multiple connections to a server supporting this feature. Each connection would issue it's own range of headers to download. The responses would then be collated in the necessary order to obtain the desired file. The size of the ranges can be pre-calculated using an initial HTTP HEAD request, which returns the actual size of the file in the Content-Length response header; the task of downloading the file may now be split into suitable chunks.
I'd recommend reading about Segmented downloading, thinking of a way to implement it in Java and than asking concrete questions if you have any.
This problem relates to the Restlet framework and Java
When a client wants to discover the resources available on a server - they must send an HTTP request with OPTIONS as the request type. This is fine I guess for non human readable clients - i.e. in code rather than a browser.
The problem I see here is - browsers (human readable) using GET, will NOT be able to quickly discover the resources available to them and find out some extra help documentation etc - because they do not use OPTIONS as a request type.
Is there a way to make a browser send an OPTIONS/GET request so the server can fire back formatted XML to the client (as this is what happens in Restlet - i.e. the server response is to send all information back as XML), and display this in the browser?
Or have I got my thinking all wrong - i.e. the point of OPTIONS is that is meant to be used inside a client's code and not meant to be read via a browser.
Use the TunnelService (which by default is already enabled) and simply add the method=OPTIONS query parameter to your URL.
(The Restlet FAQ Q19 is a similar question.)
I think OPTIONS is not designed to be 'user-visible'.
How would you dispatch an OPTIONS request from the browser ? (note that the form element only allows GET and POST).
You could send it using XmlHttpRequest and then get back XML in your Javascript callback and render it appropriately. But I'm not convinced this is something that your user should really know about!