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.
Related
I am writing a Java GAE app and relying on URL Fetch to send HTTP requests to other servers (see here. Up until this point, I had been using their HttpUrlConnection interface implementation in order to use the URL Fetch service. However, I am rewriting my app to use the low-level API instead of HttpUrlConnection because I want to send asynchronous HTTP requests.
My question: What is the URL Fetch low level API equivalent of HttpUrlConnection.getResponseMessage():String? Based on what I see from the low-level API javadoc for HTTPResponse, I am not sure of what method I should use. I can get the response code alright, but I'd like to read a useful message along with the code, especially for when an error occurs.
Thanks.
I enabled channel presence in google app engine, so I get a "ping" whenever a client connects/disconnects a channel. This is great! However, it's not enough. I would like additional information. For example: which page the client is on (i.e., the uri the client sees), or additional JS variables.
I didn't find any mention of this on google's tutorials. How do I do this, and is it even possible?
Thanks!
It's not possible for technical reasons -- the server generating those requests has no knowledge of the state of the client. If you want that data for connect, though, you could manually POST (to a different URL) when you get the onopen callback.
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 need to make an HTTP request to a resource that looks like "xy:index.html" in Java.
The HTTP implementation does not have to be sophisticated. I just need to be able to do this to avoid same-origin violations when running in development mode for a GWT app by forwarding HTTP requests on the server-side to the "xy" protocol.
Any clues about how I may be able to do this would be extremely appreciated. I feel like I'm a bit out of my league on this one ;)
I'm not sure if I understand the question properly but perhaps you can register a URL handler. This link has some info about how to do that. Perhaps you can register a custom handler for the xy: protocol and re-use the HTTP URL handlder for the real work.
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!