Response Bodies

This reference describes how the Servlet Interceptor handles response bodies of various types. Much of this behavior depends on the protocols WritableBody and WritableBodyAsync. See Important Protocols for details about those.

The exact handling of the response body depends on the Java or Clojure type of the value in the :body key of the response map.

Type Default content type Serialization Async?

byte array

application/octet-stream

direct byte copy

no

string

text/plain

bytes according to platform’s default character encoding

no

Clojure collection

application/edn

text representation of data, same as Clojure’s writer

no

Clojure function

nil

depends on the function

no

File

application/octet-stream

bytes of the file copied to the output stream

no

InputStream

application/octet-stream

bytes of the input stream copied to the output stream

no

ReadableByteChannel (NIO)

application/octet-stream

bytes of the channel copied to the output stream

yes

ByteBuffer (NIO)

application/octet-stream

bytes of the buffer copied to the output stream

yes

core.async channel

nil

see below

yes

nio Channel

When the response body is a ByteBuffer or an NIO Channel, then Pedestal will convert the response to asynchronous processing. This returns the thread to the container’s request processing thread pool, and the container will (efficiently) stream the contents of the buffer or channel to the client.

Core Async Channel

When a core.async channel delivers a message, that message is written to the stream, using any of the synchronous dispatches above. The message from the channel must not be another channel, it must be a value that can be immediately acted upon.

Function

When the body is, in fact, a function, then Pedestal will invoke the function with a java.lang.OutputStream; the function’s responsibility is to write the actual response to that stream.