Ænðr E. FeldstrawDec 27, 2018
#YesterdayILearned that the new #java.net.http #HttpClient (introduced in Java 11) no longer gives access to the server's HTTP status message, nor its error stream. The older #HttpURLConnection did do that.

The new client lets us set request headers more easily. However, I found no way to lift the restriction on the Content-Length header. The older version let us switch that off using either a command-line switch or explicit code.

The new client supports HTTP2. So that's good.
Show threadÆnðr E. FeldstrawDec 27, 2018
Yesterday was the first time in years a remote #REST #API server required me to send the #ContentLength #requestHeader. The #HTTP component I was using, #HttpURLConnection by Sun, outright refused to set it.

I looked up the HTTP RFC: yes, it is called Content-Length, and yes, it's a count of 16-bit characters. And it can be used only if neither streaming nor chunking the contents. My code met those requirements.

What was going on?
Show threadÆnðr E. FeldstrawDec 27, 2018
So I scoured the web (thank you, mr. Lee) to find that some time ago some HTTP tooling suppliers imposed a restriction on that and several other request headers that they deemed dangerous to security.

And the supplier of the tool built into my programming ecosystem, Sun, turned out to have done just that.

And they did more.

They provided an escape. A switch to lift their restriction for those of us who pretend to know what we're doing.

Now I could set the Content-length header.
Show threadÆnðr E. FeldstrawDec 27, 2018
It didn't help, unfortunately. The remote REST API server still failed to accept my request.

So I thought: let's switch HTTP components. Let's try that new one released by Oracle with Java 11.

Had some adjustments to perform.

All connecting and download requests still worked fine. Upload requests still failed.

But: different errors! I was getting somewhere!

And for some reason some GZipped response bodies. Erratically.
Show threadÆnðr E. Feldstraw
I was sure I wasn't asking for GZipped response bodies. So I looked up the #HTTP RFC once more for the #AcceptEncoding #requestHeader. It lets us set the kinds of encoding we like (compress, deflate, etc.) and also set a quality indicator.

If set to 0 for an encoding, we tell the remote server not to supply it.

Yay!

Or not: the remote REST API server I was addressing responded, saying they didn't like my Accept-Encoding header.

So… then what?
Dec 27, 2018 at 1:05pmMastalab
Show threadÆnðr E. FeldstrawDec 27, 2018
Then I noticed that this new #HTTP client in #Java11 had HTTP2 turned on by default. It should downstep to HTTP1.1 automatically if the remote server indicates it doesn't speak version 2.

So I explicitely made that client talk HTTP1.1.

To no avail.

But that wasn't apparent immediately. First I thought it helped: the 1st response body after switching wasn't GZipped.

And the one after that was.

And the one after that wasn't.

What?!

So I reached out to their support.
Show threadÆnðr E. FeldstrawDec 27, 2018
Let's see what today will bring. This isn't over. A solution must be found, otherwise we can't communicate with that remote platform via REST API, and we'll have to find alternate communication methods.

And my coworkers aren't going to enjoy manual data entry.