Kcar - bytestream to Rack response converter

Ruby
1

kcar features an HTTP parser that will convert a bytestream into a
3-element array suitable for use as a Rack response. It is IO interface
agnostic, so it may be used with HTTP streams over Unix domain sockets,
regular files, FIFOs, StringIOs as well as traditional TCP sockets.

== Features

  • RFC2616-compliant Ragel+C parser adapted from Unicorn and Mongrel

  • decodes chunked response bodies with an optional pass-through mode
    (to avoid rechunking with Rack::Chunked)

  • handles odd things like trailers and multiline headers

  • streaming interface for response bodies allows for incremental
    processing of arbitrarily large responses.

== Problems

  • kcar is only lightly tested and is not yet aware of all quirks found
    in
    all real (possibly broken) web servers.

== Install

If you’re using a packaged Ruby distribution, make sure you have a C
compiler and the matching Ruby development libraries and headers.

If you use RubyGems:

gem install kcar

Otherwise grab the latest tarball from:

http://bogomips.org/kcar/files/

Unpack it, and run “ruby setup.rb”

== Usage:

While you can use the Kcar::Parser directly, you’ll usually want the
higher-level interface of Kcar::Response:

require 'rack' # for Rack::Utils::HeaderHash, which is optional
require 'socket' # for TCPSocket
require 'kcar'
sock = TCPSocket.new('example.com', 80)
sock.write("GET / HTTP/1.0\r\n\r\n")

# instead of a Rack::Utils::HeaderHash object below, you can also
# pass a regular Hash or Array object.
response = Kcar::Response.new(sock, Rack::Utils::HeaderHash.new)
status, headers, body = response.rack

You can now do further processing on the status, headers, or iterate
through the body with body.each.

== Development

You can get the latest source via git from the following locations:

git://git.bogomips.org/kcar.git
git://repo.or.cz/kcar.git (mirror)

You may browse the code from the web and download the latest snapshot
tarballs here:

Inline patches (from “git format-patch”) to the mailing list are
preferred because they allow code review and comments in the reply to
the patch.

We will adhere to mostly the same conventions for patch submissions as
git itself. See the Documentation/SubmittingPatches document
distributed with git on on patch submission guidelines to follow. Just
don’t email the git mailing list or maintainer with kcar patches.

== Contact

All feedback (bug reports, user/development discussion, patches, pull
requests) go to the mailing list: mailto:[email protected]

== TODO

Patches to [email protected] (via git format-patch + git send-email)
for
these would be greatly appreciated

  • optional drop-in monkey patch for Net::HTTP
  • optional EventMachine support
  • optional Rev support