Response buffer middleware doesn't handle Transfer-Encoding: chunked for streaming responses

[Mubramaj]

Problem

The current response buffer middleware only bypasses buffering for text/event-stream content types, but doesn't handle Transfer-Encoding: chunked responses. This breaks streaming applications that use chunked encoding with other content types.

Real-world Impact

I encountered this issue when deploying an application using MessageBus for long-polling with chunk encoding. The application sets Transfer-Encoding: chunked with text/plain content type, but the proxy was buffering the response instead of streaming it, breaking the long-polling functionality.

Current Behavior

func (w *bufferedResponseWriter) ShouldSwitchToUnbuffered() bool {
    contentType, _, _ := strings.Cut(w.Header().Get("Content-Type"), ";")
    return contentType == "text/event-stream"
}

Proposed Solution

Check for Transfer-Encoding: chunked header in addition to text/event-stream:

func (w *bufferedResponseWriter) ShouldSwitchToUnbuffered() bool {
    // Check for explicit streaming content types
    contentType, _, _ := strings.Cut(w.Header().Get("Content-Type"), ";")
    if contentType == "text/event-stream" {
        return true
    }
    
    // Check for chunked transfer encoding - indicates streaming response
    if w.Header().Get("Transfer-Encoding") == "chunked" {
        return true
    }
    
    return false
}

Justification

When a server explicitly uses Transfer-Encoding: chunked, it's signaling that the response is being generated dynamically/streamed. RFC 7230 indicates chunked encoding is for "dynamically generated payload" and mentions its use in "long polling" scenarios.

Testing

I've already implemented comprehensive unit tests covering:

• Existing SSE behavior (unchanged)
• Chunked encoding with various content types
• Regular responses (still buffered)

I apologize - I got a bit ahead of myself and already opened a pull request #164 before discovering the discussion-first workflow. I should have started here first!

The PR includes the implementation and comprehensive tests, but I'm happy to close it and wait for discussion consensus before proceeding. I wanted to make sure the solution was well-tested, but I realize now I should have followed the proper process.

Would this approach be valuable for kamal-proxy? Happy to adjust based on feedback here before moving forward.

[kevinmcconnell]

@Mubramaj thanks for this. I agree that Transfer-Encoding: chunked is a good signal that the upstream expects to be able to deliver those chunks to the client immediately. Seems like a solid change to me 👍

Your linked PR looks great too; I'll get that into the next release. Thanks again.