Respond with a response object?

[ubermajestix]

So I grabbed this library b/c, yes, http in ruby sucks, and this does not.

However, I wanted to do a HEAD request and since you just return the body, I get nil.

So I added a response object that returns body and status so HEAD is useable.

Thoughts?

[tarcieri]

I had planned to do something similar to this and can probably start from your work. I definitely wanted to use Http::Request (along with Http::Response) objects, with the goal of using the same objects for both client and server (i.e. the Http::Request generated by a client is the same object that will be generated by the server's Http request parser)

However, "Http.get" is intended to be a shorthand syntax. I wanted HttpClient.get to return a response object by default (i.e. the longer stuff is OOP by default, the shorthand just does the simple thing), and allow you to override either by setting :response => :object or :response => :body/:parsed_body

That said I may try to pull this tonight and put it more in line with what I had in mind.

[ubermajestix]

I agree with the shorthand doing the simple thing like "Http.head" just returns the status and "HttpClient.head" returns the full response object.

I also like the override to the shortcut (or the long hand) so you can just jump arbitrarily far into the response object by providing a path to what you want (:body/:parsed_body, :status or :headers/:content_type etc...)

Let me know if you need a hand with anything.

Digging the library so far! I really hate ALL the http libs too so I'm happy to contribute to their demise.

[tarcieri]

I merged this and changed a few things.

The default behavior for all verbs besides Http.head is still to return :parsed_body. Http.head now returns an Http::Response object.

I had it grab headers too (just realized I forgot to note that in the commit message, whoops)

I also changed Http::Response to be more like a struct. The initialize method sets its default state, but presently doesn't accept any arguments. I'd like for the Ragel parser to eventually construct Http::Response objects, and I plan to expose the parser as a set of callback methods that act on the parser's present state. This will be a lot slower than, say, the Mongrel parser, but still give you flexible control over how the response objects are built. JRuby should be able to inline the parser with InDy (provided HotSpot doesn't give up due to "irreducible complexity")

tl;dr: merged!