New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rack-based API for the mruby handler #478

Closed
kazuho opened this Issue Sep 1, 2015 · 12 comments

Comments

Projects
None yet
5 participants
@kazuho
Member

kazuho commented Sep 1, 2015

At the moment, the mruby handler API is based on mod_mruby / ngx_mruby, which is based on the handler API of the Apache HTTP server.

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.

cc: @matsumoto-r @tatsuhiro-t
see also: #469

@kazuho kazuho added the mruby label Sep 1, 2015

@udzura

This comment has been minimized.

Show comment
Hide comment
@udzura

udzura Sep 2, 2015

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

  • Rack's specification is small, and basically using Ruby's core feature and data structure(such as Array, Hash). Implementing Rack in of mruby(web use case set) seems to be useful
  • web use case set means that we build mruby with IO and Enumerable extensions
  • In another words, core mruby now have a difficulty in implementing a full spec of Rack.
    • e.g. Rack's environment Hash keys rack.input, rack.errors and rack.hijack_io should have a value of IO(-like) object.
    • And especially 3rd element of response format should respond to each, which seems not to be included in mruby core-of-core[Citation required...]

In use case

  • mruby server extentions doesn't always return raw response, but CRuby Rack does.

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 commented Sep 2, 2015

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

  • Rack's specification is small, and basically using Ruby's core feature and data structure(such as Array, Hash). Implementing Rack in of mruby(web use case set) seems to be useful
  • web use case set means that we build mruby with IO and Enumerable extensions
  • In another words, core mruby now have a difficulty in implementing a full spec of Rack.
    • e.g. Rack's environment Hash keys rack.input, rack.errors and rack.hijack_io should have a value of IO(-like) object.
    • And especially 3rd element of response format should respond to each, which seems not to be included in mruby core-of-core[Citation required...]

In use case

  • mruby server extentions doesn't always return raw response, but CRuby Rack does.

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.

@matsumotory

This comment has been minimized.

Show comment
Hide comment
Contributor

matsumotory commented Sep 2, 2015

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Sep 2, 2015

Member

@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.

  • mruby server extentions doesn't always return raw response, but CRuby Rack does.

That's true.

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.

Member

kazuho commented Sep 2, 2015

@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.

  • mruby server extentions doesn't always return raw response, but CRuby Rack does.

That's true.

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.

@udzura

This comment has been minimized.

Show comment
Hide comment
@udzura

udzura Sep 2, 2015

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.

  • Request object format (which is like Rack's env and abstracts difference in ngx/mod/h2o mruby data structure)
  • Instructions to server in response phase (instead of raw response, but easily imaginable from Rack's response Array)

udzura commented Sep 2, 2015

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.

  • Request object format (which is like Rack's env and abstracts difference in ngx/mod/h2o mruby data structure)
  • Instructions to server in response phase (instead of raw response, but easily imaginable from Rack's response Array)
@matsumotory

This comment has been minimized.

Show comment
Hide comment
@matsumotory

matsumotory Sep 2, 2015

Contributor

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:

  • the environment like REQUEST_METHOD
  • the Rack-specific variables like rack.url_scheme
Contributor

matsumotory commented Sep 2, 2015

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:

  • the environment like REQUEST_METHOD
  • the Rack-specific variables like rack.url_scheme
@zzak

This comment has been minimized.

Show comment
Hide comment
@zzak

zzak Sep 6, 2015

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.
Rack is also a library, and depends on several parts of Ruby's standard library that don't exist (yet) in mruby.

IMO this is one of the roadblocks to providing Rack in mruby is the missing libraries. For example, URI is used in rack/utils for parsing urls and request parameters, and is also useful outside of Rack when developing web applications.

Aside from that, I'm very 👍 on providing this API in mruby. <3

zzak commented Sep 6, 2015

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.
Rack is also a library, and depends on several parts of Ruby's standard library that don't exist (yet) in mruby.

IMO this is one of the roadblocks to providing Rack in mruby is the missing libraries. For example, URI is used in rack/utils for parsing urls and request parameters, and is also useful outside of Rack when developing web applications.

Aside from that, I'm very 👍 on providing this API in mruby. <3

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Sep 8, 2015

Member

@zzak Thank you for your comment.

It's important to note that Rack is not only a specification, and API.
Rack is also a library, and depends on several parts of Ruby's standard library that don't exist (yet) in mruby.

IMO this is one of the roadblocks to providing Rack in mruby is the missing libraries.

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).
In the long term, hopefully we could find a way to either provide a mruby-based library implementation of Rack or get the Rack library adjusted so that some of its modules can be run on mruby.

Member

kazuho commented Sep 8, 2015

@zzak Thank you for your comment.

It's important to note that Rack is not only a specification, and API.
Rack is also a library, and depends on several parts of Ruby's standard library that don't exist (yet) in mruby.

IMO this is one of the roadblocks to providing Rack in mruby is the missing libraries.

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).
In the long term, hopefully we could find a way to either provide a mruby-based library implementation of Rack or get the Rack library adjusted so that some of its modules can be run on mruby.

@takahashim

This comment has been minimized.

Show comment
Hide comment
@takahashim

takahashim Sep 9, 2015

Contributor

Just FYI: if you would like to support HTTP/2 in Rack(-like) API, issues of the_metal (tenderlove's spike for Rack 2.0) https://github.com/tenderlove/the_metal/issues , especially tenderlove/the_metal#5 , might be helpful.

Contributor

takahashim commented Sep 9, 2015

Just FYI: if you would like to support HTTP/2 in Rack(-like) API, issues of the_metal (tenderlove's spike for Rack 2.0) https://github.com/tenderlove/the_metal/issues , especially tenderlove/the_metal#5 , might be helpful.

@kazuho kazuho referenced this issue Sep 9, 2015

Merged

switch to rack-based API #489

3 of 3 tasks complete
@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Sep 10, 2015

Member

@takahashim 👍 Thank you for the info!

Member

kazuho commented Sep 10, 2015

@takahashim 👍 Thank you for the info!

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Sep 10, 2015

Member

With #489 being merged, the work is almost complete.

Leftovers are:

  • #494 provide a way to send contents of a file (essentially revives #send_file method introduced in #471)
  • #491 preserve the method in case x-reproxy-url header is used with 307 or 308 status
  • #495 accept multi-line headers
Member

kazuho commented Sep 10, 2015

With #489 being merged, the work is almost complete.

Leftovers are:

  • #494 provide a way to send contents of a file (essentially revives #send_file method introduced in #471)
  • #491 preserve the method in case x-reproxy-url header is used with 307 or 308 status
  • #495 accept multi-line headers
@matsumotory

This comment has been minimized.

Show comment
Hide comment
@matsumotory

matsumotory Sep 10, 2015

Contributor

👍

Contributor

matsumotory commented Sep 10, 2015

👍

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Sep 11, 2015

Member

complete!

Member

kazuho commented Sep 11, 2015

complete!

@kazuho kazuho closed this Sep 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment