ServerResultUtils
Related Doc:
package common
The connection header logic to use for the result.
Used to indicate that a result can't be streamed.
Used to indicate that a result can't be streamed. Offers an alternative result that can be sent instead.
A stream where the response should be chunk encoded.
A stream where the response should be chunk encoded. This is usually used for an HTTP 1.1 connection where the response has unknown size.
Indicates the streaming strategy to use for returning the response.
Used for responses that have unknown length and should be delimited by the connection closing.
Used for responses that have unknown length and should be delimited by
the connection closing. This is used for all HTTP 1.0 responses with
unknown length, since HTTP 1.0 doesn't support chunked encoding. It can
also be used for some HTTP 1.1 responses, if chunked encoding isn't
desired for some reason, e.g. see the Results.feed method.
A stream with a known length where the Content-Length header can be set.
A stream with bytes that are already entirely known.
A stream with bytes that are already entirely known. The Content-Length can be sent and an efficient streaming strategy can be used by the server.
A stream where the response has already been encoded by the user, e.g.
A stream where the response has already been encoded by the user, e.g. using
Results.chunked. The server may be able to feed this encoded data directly -
or it may need to reverse the encoding before resending it. :(
No Connection header should be sent.
No Connection header should be sent. Used on an HTTP 1.0
connection where the default behavior is to close the connection.
No Connection header should be sent.
No Connection header should be sent. Used on an HTTP 1.1
connection where the default behavior is to keep the connection
open.
A Connection: close header should be sent.
A Connection: close header should be sent. Used to
force an HTTP 1.1 connection to close.
A Connection: keep-alive header should be sent.
A Connection: keep-alive header should be sent. Used to
force an HTTP 1.0 connection to remain open.
Used for responses that may not contain a body, e.g.
Used for responses that may not contain a body, e.g. 204 or 304 responses. The server shouldn't send a body and, since the response cannot have a body, the Content-Length header shouldn't be sent either.
Update the result's Set-Cookie header so that it removes any Flash cookies we received in the incoming request.
Analyze the Result and determine how best to send it.
Analyze the Result and determine how best to send it. This may involve looking at headers, buffering the enumerator, etc. The returned value will indicate how to stream the result and will provide an Enumerator or Array with the result body that should be streamed.
CannotStream will be returned if the Result cannot be streamed to the given client. This can happen if a result requires Transfer-Encoding but the client uses HTTP 1.0. It can also happen if there is an error in the Result headers.
The ConnectionHeader returned for a successful result will indicate how the header should be set in the response header.
Start reading an Enumerator and see if it is only zero or one elements long.
Start reading an Enumerator and see if it is only zero or one elements long. - If zero-length, return Left(None). - If one-length, return the element in Left(Some(el)) - If more than one element long, return Right(enumerator) where enumerator is an Enumerator that contains *all* the input. Any already-read elements will still be included in this Enumerator.
Given a map of headers, split it into a sequence of individual headers.
Given a map of headers, split it into a sequence of individual headers.
Most headers map into a single pair in the new sequence. The exception is
the Set-Cookie header which we split into a pair for each cookie it
contains. This allows us to work around issues with clients that can't
handle combined headers. (Also RFC6265 says multiple headers shouldn't
be folded together, which Play's API unfortunately does.)