Skip to content

Add streaming bodyStream() overloads to HttpResponseMessage.Builder#55

Draft
ahmedmuhsin wants to merge 1 commit into
Azure:devfrom
ahmedmuhsin:feat/http-response-bodystream
Draft

Add streaming bodyStream() overloads to HttpResponseMessage.Builder#55
ahmedmuhsin wants to merge 1 commit into
Azure:devfrom
ahmedmuhsin:feat/http-response-bodystream

Conversation

@ahmedmuhsin

@ahmedmuhsin ahmedmuhsin commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds two new streaming overloads to HttpResponseMessage.Builder so HTTP-triggered functions can return response bodies without buffering them in memory.

Companion to the Java worker proxy-streaming PR: Azure/azure-functions-java-worker#877.

New API

public interface HttpResponseMessage {
    interface Builder {
        // existing
        Builder body(Object body);

        // new
        Builder bodyStream(InputStream stream);
        Builder bodyStream(IOConsumer<OutputStream> writer);
    }
}

@FunctionalInterface
public interface IOConsumer<T> {
    void accept(T value) throws IOException;
}

bodyStream(InputStream) is for the common case of forwarding an upstream stream (Blob download, large file, etc.). bodyStream(IOConsumer<OutputStream>) is for callback-driven streaming such as Server-Sent Events.

The buffered body(Object) overload is unchanged.

Versioning

This bumps the library to 1.4.0-SNAPSHOT. The Java worker proxy-streaming PR depends on this snapshot. Release once both PRs are reviewed and merged.

Backward compatibility

Pure addition — no existing signatures change. Functions that never call bodyStream(...) see no behavior change. Old worker versions that don't know about the streaming outcome simply continue to use the buffered body(...) path.

Adds two new default methods to HttpResponseMessage.Builder for
streaming HTTP responses without buffering the entire payload in
memory:

  Builder bodyStream(InputStream stream)
  Builder bodyStream(IOConsumer<OutputStream> writer)

Both methods delegate to body(Object), so existing runtimes that do
not implement the streaming write path continue to work via their
existing type dispatch on body. Runtimes that do implement streaming
(e.g. the Java worker's HTTP proxy path) detect InputStream / IOConsumer
on the body and write incrementally to the HTTP response.

Also adds the IOConsumer<T> functional interface (throwing IOException),
since java.util.function.Consumer does not allow checked exceptions and
streaming writers commonly throw IOException.

Version bumped: 1.3.0 -> 1.4.0-SNAPSHOT (the corresponding worker
change consumes this SNAPSHOT until release).
ahmedmuhsin added a commit to ahmedmuhsin/azure-functions-java-worker that referenced this pull request Jun 12, 2026
GitHub-triggered ADO PR runs can't set pipeline parameters interactively,
so flip the defaults to point at the fork branch that contains the matching
unpublished library snapshot:

  buildAdditionsFromSource: true
  additionsRepoUrl:        https://github.com/ahmedmuhsin/azure-functions-java-additions.git
  additionsBranch:         feat/http-response-bodystream

REVERT THIS COMMIT before merge — once the companion PR
(Azure/azure-functions-java-additions#55) lands and a matching
`azure-functions-java-core-library` version is published to Maven Central,
the defaults should return to:

  buildAdditionsFromSource: false
  additionsRepoUrl:        https://github.com/Azure/azure-functions-java-additions.git
  additionsBranch:         dev
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant