My standard usecase for it is adding HttpObjectAggregator to the pipeline, both for server and client connections.

Oh, interesting. Why do you add it? Is it to avoid dealing with InputStreams that are still being written to? Or something else? When people set max-request-body-size, Aleph adds it by default, if that's your use case.

Yes, it's both for being able to safely slurp the :body inputstream without worrying about blocking, and for limiting the max body size. I've put these middlewares to pipeline-transform back when the max-request-body-size was not done/merged, and the code kinda stuck around.

To copy the "Expect" header before it got removed by the continue-handler https://github.com/clj-commons/aleph/pull/686#issuecomment-1673837252

(Edge case of the S3 API which supports only HTTP1.1 AFAIK)

@U06PNK4HG We could make aggregation a more general option, so people don't have to fiddle with pipeline-transform. I thought most people were using bs/to-string or similar fns to avoid dealing with InputStreams, but maybe that's not true?

bs/to-string would allocate an extra string which I don't really need since I'm going to parse the JSON body into maps anyway.

The changes won't affect me directly since we stay on our fork of Aleph. I'm just voicing out the usecase, I certainly don't know if the way we do it right now is the best one:)

Wrote up an issue at https://github.com/clj-commons/aleph/issues/692, pelase add comments there

re safety check: that error would not be thrown when only setting http1-pipeline-transform instead? Would make sense IMHO if you intentionally want to modify the pipeline only for HTTP 1 for some reason.

as for pipeline-transform uses: We use it for adding a read timeout handler. This turns out to be trickier than expected due to HTTP keep-alive. I'll elaborate on the ticket. (never mind, that's due to an implementation detail on our end)

Do the idle handlers not meet your needs for some reason?

Right, that's what I was hinting at: With connection keep-alive (especially so when sitting behind a proxy), setting the timeout low enough to serve as a read timeout, the connection would often get closed in between two requests for no good reason. In our particular case, we're doing long polling where we keep a requests open for up to 5 seconds. Thus, we have to set idle timeout to something higher than 5 seconds. But that is way too high to serve as a read timeout at the same time.