Currently the API says that if we want to handle websockets along with normal routes we have to use listen https://juliaweb.github.io/HTTP.jl/stable/guides/migration-1x/#WebSockets which means we have to adapt to streaming responses using e.g. https://juliaweb.github.io/HTTP.jl/stable/api/server/#HTTP.streamhandler .
In this case response bodies must be buffered so they can be written into a stream, even if the response body is an AbstractVector{UInt8}. I guess this means the highest performance code paths can't be reached. Is this assumption correct?
More generally there could be cases where we have something like a middleware that sometimes wants to work in a streaming fashion, modifying the responses on-the-fly, in other cases wants to work on a whole buffer at-a-time, and in other cases wants to pass them through. Would it be possible to support this use case?
Currently the API says that if we want to handle websockets along with normal routes we have to use
listenhttps://juliaweb.github.io/HTTP.jl/stable/guides/migration-1x/#WebSockets which means we have to adapt to streaming responses using e.g. https://juliaweb.github.io/HTTP.jl/stable/api/server/#HTTP.streamhandler .In this case response bodies must be buffered so they can be written into a stream, even if the response body is an AbstractVector{UInt8}. I guess this means the highest performance code paths can't be reached. Is this assumption correct?
More generally there could be cases where we have something like a middleware that sometimes wants to work in a streaming fashion, modifying the responses on-the-fly, in other cases wants to work on a whole buffer at-a-time, and in other cases wants to pass them through. Would it be possible to support this use case?