Fixed an issue in sync clients where empty response payloads could cause a null pointer exception.

[millems]

Before this change, we passed null to response transformers when the HTTP client returned empty. Our built-in response transformers expected non-null, so this would fail. This change passes an empty body to response transformers, instead.

Fixes #3359

[joviegas]

Query , just thinking out loud :
Since this issue is caused by PR #3346 and specific to HttpUrlConnection's handling of HEAD requests.

Why not we create SdkHttpEmptyStream in tryGetInputStream

     private Optional<InputStream> tryGetInputStream() {
            return responseHasNoContent()
                   ? new SdkHttpEmptyStream()
                   : getAndHandle100Bug(() -> invokeSafely(connection::getInputStream), true);
        }

where SdkHttpEmptyStream is emptyInputStream same as HttpURLConnection and then this check in Crc32Validation class

    public static SdkHttpFullResponse validate(boolean calculateCrc32FromCompressedData,
                                               SdkHttpFullResponse httpResponse) {

        if (!httpResponse.content().isPresent() || httpResponse.content() instance of  SdkHttpEmptyStream.class) {
            return httpResponse;
        }

        return httpResponse.toBuilder().content(
            process(calculateCrc32FromCompressedData, httpResponse,
                    httpResponse.content().get())).build();
    }

Since we are overwriting the EmptyInputStream as Optional.empty() in UrlConnectionHttpClient, I think we should pass similar sdk identified SdkEmptyInputStream.

My concern is by handling the Null pointer exception we might mask bugs where Service actually sends a Null content stream ,

[millems]

The reason I made this change is that HttpExecuteResponse contains an Optional<AbortableInputStream> responseBody, but core fails to handle the case that responseBody is empty. That's clearly a case that needs to get handled by core, regardless of the HTTP client. There's no fixes we could make to the URL connection client to avoid that problem.

We could have "re-hid" the problem by returning an empty stream instead of no stream, but that doesn't feel like fixing the root cause.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

66.7% Coverage
0.0% Duplication