Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Rack-based API for the mruby handler #478
However, the API is unfamiliar to developers (compared to the huge number of users familiar with Ruby). It is also hard to maintain compatibility as we add features to the handler.
OTOH, Rack exists as a very popular API for writing HTTP handlers. It is well-known, well-documented, and extensible (in sense that all information are communicated via lists of headers).
So the question is: can't we switch the mruby handler API to Rack (or subset of)?
Doing so would be beneficial to the users; with Rack-based API they can run their request/response annotation logics (that is what the mod_mruby, ngx_mruby, H2O's mruby handler, nghttpx's mruby support is all trying to provide) either within the HTTP servers or within their application servers (such as Unicorn). It would also help the adoption of the (m)ruby-scriptable HTTP servers, considering the popularity of Rack.
I have been in touch with both Rails and Sinatra/Padrino community in a few years, so I have a bit about Rack and its CRuby implementation.
My rough impression:
In spec implementation
In use case
Rack of mruby sounds cool, but maybe this should be an mruby-optimized one, and be just close but not the same one as CRuby Rack.
@udzura Thank you for your comments.
I agree that it would not be necessary (or practical) to support all aspects of Rack in our mruby handler.
OTOH we could still use certain status codes for identifying such do-not-return-response use cases. For example, in case of H2O's mruby handler, we could use status value of -1 to indicate that the handler has decided not to handle the request.
What I am saying is that IMO it would be easier for both server implementers and the users if we choose Rack as the basis of the API (with certain additions to cover the needs specific to H2O or any other httpd) than trying to define every aspect by ourselves.
I see. As one of users-to-be, it is helpful to be able to use common rules which is easily understandable with Rack's information.
IMO, these specs seems to be useful.
It's nice idea.
I can control the compatibility between mod_mruby and ngx_mruby. But, as the increase of httpd which supports mruby, I can't keep these compatibility. So, I also want the specification of "mruby in HTTP Server". Rack specification is simple looks good to me.
For now, I think we should use the part of the spec of Rack for C-API and C-struct in httpd like the followings:
I think this is a great idea, and one that I've been considering.
It's important to note that Rack is not only a specification, and API.
IMO this is one of the roadblocks to providing Rack in mruby is the missing libraries. For example, URI is used in
Aside from that, I'm very
referenced this issue
Sep 8, 2015
@zzak Thank you for your comment.
Thank you for bringing up the important aspect. I agree.
In short term, I hope it would not be a great issue for my intention to try to offer mruby (and Rack spec.) as a better alternative to regex-based request mangling (i.e. mod_rewrite).