h2c | HTTP/2 Cleartext Wrappers | HTTP library

Because you can upgrade to h2 or h2c. Yes the former would be negotiated automatically if you used HTTPS initially, but if you didn’t then it’s valid to say you can use h2 if you do switch to that. You could also send back a 301/302 redirect which would effectively redirect you to HTTPS and so h2 but since the upgrade mechanism is not used by browsers maybe you can’t assume the sending application will use those?

A bigger question to me is why the upgrade mechanism exists at all! As I think you’re implying, if you can talk HTTPS then you’ll be using HTTP/2 if you can and so don’t need the upgrade mechanism. And the reason browsers only support HTTP/2 over HTTPS is its so unreliable over HTTP as middleboxes assume HTTP/1 - which means the only use of h2c is for non-browser communication where you’re basically in control of the end to end connection so can skip the upgrade dance and go straight the h2c (aka the “prior knowledge” method of using HTTP/2). The preface message can always be used to reject and/or fallback to HTTP/1 if a client unexpectedly doesn’t support HTTP/2.

In the meantime the upgrade mechanism does cause real problems. For example nginx used to blindly forward this on even if it was already using HTTP/2 to the client. So if a backend Apache server saw the nginx connection was HTTP/1.1 and then suggested HTTP/2 then nginx forward that on to the browser which gets confused as it’s already talking HTTP/2 (to nginx). Safari used to handle this really badly and break and refuse to display the site basically. Yes maybe if Apache hadn’t suggested h2 in the upgrade header this wouldn’t have happened (is that where your question stems from?) but technically it’s nginx at fault here. I can’t remember if they fixed this but think they did.

Anyway, this has been recognised by the HTTP Working Group and they are likely to remove the upgrade mechanism for the next update to the HTTP/2 spec.

While we’re at it, I do wonder if there’s much use for h2c? Obviously the browsers not supporting it puts a severe dent in its usage but, as I say, that was go good reason. Is it used much in non-browser contexts? Difficult to say and even if it is would the requirement to use HTTPS be that much of an extra burden and/or be more reliable?

Edit: to answer your further questions.

Yes all of that is correct.

Case 1: You cannot use h2 of HTTP so it cannot be used via the upgrade header. It’s arguable whether h2 should be in the upgrade header for this reasons and, as you point out, it’s not listed in the IANA registry of allowed upgrade headers. My understanding is this is for upgrading a connection over the same transport protocol and while h2 would still be over HTTP over TCP, so technically over the same transport protocol, it does need HTTP so does need a new connection (and usually different port) so definitely stretching the definition of upgrade!

Case 2: Yes this is what should happen.

Case 3: Arguable but I think technically correct. I’d call that a downgrade rather than an upgrade, but the upgrade mechanism is really a “I support different protocols you might prefer” mechanism rather necessarily an “upgrade to a better protocol” header. Similar to case 1 this will likely require a new connection so again it’s arguable whether this really fits in with the upgrade mechanism as it was intended to be used.

As I say all this is fairly irrelevant, or will be soon, as it will be removed from the HTTP/2 spec.

I have an unfortunate answer to your question: Regrettably, impossible.

Some background on why this is the case:

The actual implementation of HttpRequest used by your average OpenJDK-based java-core-library implementation is not java.net.http.HttpRequest - that is merely an interface. It's jdk.internal.net.http.HttpRequestImpl.

This code has 2 separate lists of headers to send; one is the 'user headers' and the other is the 'system headers'. Your .headers() call retrieves solely the user headers, which are headers you explicitly asked to send, and, naturally, as you asked for none to send, it is empty.

The system headers is where those 6 headers are coming from. I don't think there is a way to get at these in a supported fashion. If you want to dip into unsupported strategies (Where you write code that queries internal state and is thus has no guarantee to work on other JVM implementations, or a future version of a basic JVM implementation), it's still quite difficult, unfortunately! Some basic reflection isn't going to get the job done here. It's the worst news imaginable:

• These 6 headers just aren't set, at all, until send is invoked. For example, the three headers that are HTTP2 related are set in the package-private setH2Upgrade method, and this method is passed the HttpClient object, which proves that this cannot possibly be called except in the chain of events started when you invoke send. An HttpClient object doesn't exist in the chain of code that makes HttpRequest objects, which proves this.

• To make matters considerably worse, the default HttpClient impl will first clone your HttpRequest, then does a bunch of ops on this clone (including adding those system headers), and then sends the clone, which means the HttpRequest object you have doesn't have any of these headers. Not even after the send call completes. So even if you are okay with fetching these headers after the send and are okay with using reflecting to dig into internal state to get em, it won't work.

You also can't reflect into the client because the relevant state (the clone of your httprequest object) isn't in a field, it's in a local variable, and reflection can't get you those.

A HttpRequest can be configured with custom proxies, which isn't much of a solution either: That's TCP/IP level proxies, not HTTP proxies, and headers are sent encrypted with HTTPS. Thus, writing code that (ab)uses the proxy settings so that you can make a 'proxy' that just bounces the connection around your own code first before sending it out, in order to see the headers in transit, is decidedly non-trivial.

The only solution I can offer you is to ditch java.net.http.HttpClient entirely and use a non-java-lib-core library that does do what you want. perhaps OkHttp. (Before you sing hallelujah, I don't actually know if OkHttp can provide you with all the headers it intends to send, or give you a way to register a hook that is duly notified, so investigate that first!)

I think some of your exception handling was giving you the wrong hints. If you encountered an exception, you'd have been trying to connect again, and at some point Windows complained about trying to connect to a socket that wasn't closed.

The ALPN protocol for HTTP/2 should be set to h2, and after that running your code gave me an error:

You are not executing your query in the PHP code, try to edit your code like this:

Locally you are upgrading an insecure HTTP 1.1 request to an insecure HTTP 2 request. This works with Quart and curl, but browsers including chrome do not support insecure (unencrypted) HTTP/2. For it to work in chrome I create a self signed certificate, passing the certfile and keyfile options to the run and accept the warning chrome offers when visiting the site. An example exists here.

It was just a stupid firewall issue that was blocking container out @ 443

I realized it could be solved in some cases providing "redirect": "follow" to the JSON when using a Node fetch request.

This is due to a bug in the Go runtime used at that time (1.14.2), for more details see https://groups.google.com/g/golang-announce/c/XZNfaiwgt2w/m/E6gHDs32AQAJ

It's been fixed starting from Artifactory 7.7.0, so you can just upgrade to the latest release (7.10.6 when writing this message)

The Content-Length header indicates the size of the entity body in the message, in bytes. The size includes any content encodings (the Content-Length of a gzip-compressed text file will be the compressed size, not the original size).

src

I thought I had tried this but kept running into ERR_CONTENT_LENGTH_MISMATCH because of how I was closing my gzip writer. Related Question

Final handler looked like this: