Class | EventMachine::HttpResponse |
In: |
lib/evma_httpserver/response.rb
|
Parent: | Object |
This class provides a wide variety of features for generating and dispatching HTTP responses. It allows you to conveniently generate headers and content (including chunks and multiparts), and dispatch responses (including deferred or partially-complete responses).
Although HttpResponse is coded as a class, it‘s not complete as it stands. It assumes that it has certain of the behaviors of EventMachine::Connection. You must add these behaviors, either by subclassing HttpResponse, or using the alternate version of this class, DelegatedHttpResponse. See the test cases for current information on which behaviors you have to add.
TODO, someday it would be nice to provide a version of this functionality that is coded as a Module, so it can simply be mixed into an instance of EventMachine::Connection.
chunks | [RW] | |
content | [RW] | |
headers | [RW] | |
multiparts | [RW] | |
status | [RW] |
Sugaring for Set-cookie headers. These are a pain because there can easily and legitimately be more than one. So we use an ugly verb to signify that. add_set_cookies does NOT disturb the set-cookie headers which may have been added on a prior call. set_cookie clears them out first.
add a chunk to go to the output. Will cause the headers to pick up "content-transfer-encoding" Add the chunk to a list. Calling send_chunks will send out the available chunks and clear the chunk list WITHOUT closing the connection, so it can be called any number of times. TODO!!! Per RFC2616, we may not send chunks to an HTTP/1.0 client. Raise an exception here if our user tries to do so. Chunked transfer coding is defined in RFC2616 pgh 3.6.1. The argument can be a string or a hash. The latter allows for sending chunks with extensions (someday).
Examine the content type and data and other things, and perform a final fixup of the header array. We expect this to be called just before sending headers to the remote peer. In the case of multiparts, we ASSUME we will get called before any content gets sent out, because the multipart boundary is created here.
To add a multipart to the outgoing response, specify the headers and the body. If only a string is given, it‘s treated as the body (in this case, the header is assumed to be empty).
we send either content, chunks, or multiparts. Content can only be sent once. Chunks and multiparts can be sent any number of times. DO NOT close the connection or send any goodbye kisses. This method can be called multiple times to send out chunks or multiparts.
send the contents of the chunk list and clear it out. ASSUMES that headers have been sent. Does NOT close the connection. Can be called multiple times. According to RFC2616, phg 3.6.1, the last chunk will be zero length. But some caller could accidentally set a zero-length chunk in the middle of the stream. If that should happen, raise an exception. The reason for supporting chunks that are hashes instead of just strings is to enable someday supporting chunk-extension codes (cf the RFC). TODO!!! We‘re not supporting the final entity-header that may be transmitted after the last (zero-length) chunk.
Send the headers out in alpha-sorted order. This will degrade performance to some degree, and is intended only to simplify the construction of unit tests.
Multipart syntax is defined in RFC 2046, pgh 5.1.1 et seq. The CRLF which introduces the boundary line of each part (content entity) is defined as being part of the boundary, not of the preceding part. So we don‘t need to mess with interpreting the last bytes of a part to ensure they are CRLF-terminated.
This is intended to send a complete HTTP response, including closing the connection if appropriate at the end of the transmission. Don‘t use this method to send partial or iterated responses. This method will send chunks and multiparts provided they are all available when we get here. Note that the default @status is 200 if the value doesn‘t exist.