fix: StandardHttpClient sends Expect 100-continue header value

[manusa]

Description

Relates to #4735 (might fix it)

fix: StandardHttpClient sends Expect 100-continue header value

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[manusa]

@shawkins FYI, the JDK client sends the "wrong" header value (at least on OpenJDK, but the official Javadocs aren't very relieving)

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[shawkins]

Indeed https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java#L536

And you confirmed that the api server does require the case sensitive value? Maybe @maxandersen can push through another jdk fix.

[manusa]

Indeed https://github.com/openjdk/jdk/blob/master/src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java#L536

And you confirmed that the api server does require the case sensitive value? Maybe @maxandersen can push through another jdk fix.

No, sorry, I haven't confirmed yet that changing the header value fixes it.

[manusa]

👍 Confirmed, JKube's oc:build works again once the header is sent with the correct value 100-continue.

[manusa]

I'm merging this one, we should probably discuss what to do with the JDK implementation.

[shawkins]

@manusa reviewing this more, the burden of the fix should be in the underlying go library: golang/go#57824

If for whatever reason that is not possible, we can push for a jdk change.

[manusa]

This is more aligned with what I remember about the header value. However, I think both sides would benefit from the fix.