#contentlength — Public Fediverse posts

So yes, it turns out that though our communication partner pretends to accept HTTP/2, their API server adheres to HTTP/1.1 standards. And with HTTP/1.1, the #Java11 #HttpClient will send a #ContentLength header even if the payload is 0 bytes. Which is exactly what our communication partner expects. A bit weird, and sad.

So yes, it turns out that though our communication partner pretends to accept HTTP/2, their API server adheres to HTTP/1.1 standards. And with HTTP/1.1, the #Java11 #HttpClient will send a #ContentLength header even if the payload is 0 bytes. Which is exactly what our communication partner expects. A bit weird, and sad.

It looks like #Java11 decided to completely omit the #contentLength header of an #HttpPost request if the content length equals 0 (zero). That's possible with HTTP/2, but not with HTTP/1.0 or 1.1.

The #RESTAPI server we talk to requires a content-length header even if the payload is empty. Does downgrading to HTTP/1.1 change the behavior of #JavaNetHttp? Does that get the header included?

Or do we have to override default header filtering?

It looks like #Java11 decided to completely omit the #contentLength header of an #HttpPost request if the content length equals 0 (zero). That's possible with HTTP/2, but not with HTTP/1.0 or 1.1.

The #RESTAPI server we talk to requires a content-length header even if the payload is empty. Does downgrading to HTTP/1.1 change the behavior of #JavaNetHttp? Does that get the header included?

Or do we have to override default header filtering?

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?