Is there already a way to get the HTTP/2 response header in Java? I've tried to search in some libraries like URLConnection, Undertow or even Jetty, but without success.
P.S.: I'm using JDK 1.7 on my Java Project.
Other thing, the response header of the HTTP/2 is like this?
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
Is there any website who use this version already?
My main goal is to know if a website use the HTTP/2 version or not, is there a way to know this without need to read the response header in a Java Project?
Thanks.
HTTP/2 websites typically use TLS, because browsers only support HTTP/2 over TLS.
The method you are trying to use is the HTTP/1.1 upgrade to HTTP/2 which very few sites - if any at all - support.
Your snippet of code represent a request, not a response.
If the upgrade is successful, the HTTP/2 server sends back a 101 response in HTTP/1.1 format and the response to the GET request in HTTP/2 format. This is specified in RFC 7540, section 3.2.
In order to achieve what you want, i.e. to know if a website supports HTTP/2, you have to try to connect using HTTP/2 + TLS. If the connection succeeds, you know HTTP/2 is supported. If it fails, it's not supported.
For Jetty (disclaimer, I'm the HTTP/2 module maintainer), you have to use JDK 8, and the code will look like this:
// Setup.
HTTP2Client http2Client = new HTTP2Client();
SslContextFactory sslContextFactory = new SslContextFactory();
HttpClient httpClient = new HttpClient(new HttpClientTransportOverHTTP2(http2Client), sslContextFactory);
httpClient.start();
// Does webtide.com support HTTP/2 ?
ContentResponse response = httpClient.GET("https://webtide.com/");
// No errors, yes it supports HTTP/2 !
If you get a response without errors, you are on HTTP/2, otherwise the server does not support HTTP/2.
Remember that for that code to work, you have to use JDK 8 and the proper ALPN boot jar in the bootclasspath, as specified here.
Related
Testing out connection reuse with http1.1 and http1.0 keep-alive on a service over HTTPS using the jersey client.
I have logging enabled on the jersey client:
Client client = ClientBuilder.newClient(new ClientConfig().register( LoggingFilter.class));
Also have SSL debugging enabled using the property option:
-Djavax.net.debug=ssl
This gives quite a lot of info, but jersey doesn't log the HTTP version used (i.e. if it's actually using HTTP1.0 or HTTP1.1). Is there some way to get this logged out?
Once I changed the javax.net.debug JVM option to 'all' the debug output included the data as well - including what version of HTTP was used in the requests:
-Djavax.net.debug=all
The output was not very pretty, but it worked.
I am using OkHttp3 in my Android app to make HTTP/1.x requests to my backend servers via a forward proxy, like so:
List<Protocol> protos = new ArrayList<>();
protos.add(Protocol.HTTP_2);
protos.add(Protocol.HTTP_1_1);
InetSocketAddress proxyAddr = new InetSocketAddress("proxy.example.com", 80);
Proxy proxy = new Proxy(Proxy.Type.HTTP, proxyAddr);
OkHttpClient cli = new OkHttpClient.Builder()
.proxy(proxy)
.protocols(protos)
.build();
String url = "http://www.example.com/";
Request req = new Request.Builder().url(url).build();
Response res = cli.newCall(req).execute();
I would like to upgrade to HTTP2. However, it seems to me that OkHttp3 can make HTTP2 requests only if we are not going via a HTTP proxy. So, the above code wouldn't work.
In other words, OkHttp3 supports the first 3 cases below but not the fourth. HTTP/2 below means h2 (HTTP/2 over TLS) not h2c (HTTP/2 over clear text).
a) client <-- HTTP/1.x --> upstream server
b) client <-- HTTP/1.x --> forward proxy <-- HTTP/x --> upstream server
c) client <-- HTTP/2 --> upstream server
d) client <-- HTTP/2 --> forward proxy <-- HTTP/x --> upstream server
Does anyone confirm or deny my understanding? Thanks.
OkHttp will do HTTP/2 over an HTTP proxy. You’ll need HTTPS on the server since OkHttp doesn’t implement plaintext HTTP/2.
Jesse, I tried retrieving https://www.google.com/ with Proxy.Type.HTTP via nghttp2's forward proxy nghttpx, which supports HTTP2 over TLS. Unfortunately, TLS handshaking did not happen and the forward proxy reported the following error.
... tls: handshake libssl error: error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request
From what I gather, this error means that okhttp3's proxy code is not doing TLS handshaking with the forward proxy.
This makes me think that HTTP2 over TLS via a forward proxy is kind of pointless, because the forward proxy won't be able to add any value to encrypted requests - the forward proxy is just a pass-through pipe. In fact, I think TLS via any forward proxy is pointless. End-to-end HTTP2 over TLS does make sense, but via a forward proxy doesn't.
If I try to connect to a https url with Apache Http client 3.1 like so..
HttpClient httpClient = new HttpClient()
HttpMethod method = new GetMethod("https://federation/galaxy-class/enterprise/getSheildFrequencies")
int responseCode = httpClient.executeMethod(method)
which SSL version does it use in the handshake?
If it is SSLv2, is there any way to tell it to use a later version or TLS?
At least Apache HTTP Client 4 uses the underlying JRE for SSL connections. So it's a matter of configuring the JRE (I would imagine the higher versions are enabled by default).
In an SSL handshake, the client presents it's highest supported version to the server by default. Then it's up to the server how high version it supports.
Try setting the "javax.net.debug" system property to value "ssl" so you can see the SSL handshake where the version is also displayed.
I am using Nginx to transform https to http from client to server.
I have an atmosphere configuration working well in websocket without this forwarding.
Now if I switch to https with Nginx in the middle
var request = { url: "https://localhost/writever/chat",
contentType : "application/json",
logLevel : 'debug',
transport : transport ,
enableProtocol : true,
fallbackTransport: 'long-polling'};
Websocket connection fails after a timeout and downgrades to long-polling.
Would you know if it is possible to have websocket working under these conditions?
By the way, latest nginx 1.3 supports websocket proxying - still in dev mode. Does it have an impact on an AtmosphereHandler if such a method is used?
it should not make a difference. But take a look at:
http://goo.gl/04g8F
You might want to add this header and see if that make a difference. I sincerely doubt, but try it.
-- Jeanfrancois
We are using Apache Axis client to communicate to a report server. The Apache Client uses Apache Http Client for NTLM authentication. Based on the below post
How can I get jcifs to play nicely with apache axis
it looks like it only supports the primitive NTLM. One of our machines is set to work with the recent NTLM authentication.
I want to know where is this setting where I can reset to use the primitive NTLM authentication supported by Apache Http Client.
HttpClient doesnt support NTLM v2 hence I use JCIFS library to return NTLM v1,2,3 message type as described in this website
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
I just used the JCIFS_NTLMScheme.java file from the above website to register the auth scheme and it worked !!!!
Sample client:
List authSchema = new ArrayList();
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.tempuri.JCIFS_NTLMScheme.class);
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
auth.setUsername("");
auth.setPassword("");
auth.setDomain("");
auth.setHost("");
auth.setPort();
List authPrefs = new ArrayList(1);
authPrefs.add(AuthPolicy.NTLM);
auth.setAuthSchemes(authPrefs);
stub._getServiceClient().getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.AUTHENTICATE, auth);