Purpose of config.ru (regarding server options), #245

Purpose of config.ru (regarding server options), #245

[Matthias Wächter]

Hi,

Recently, I forked rack and created a feature 
[https://github.com/rack/rack/pull/245] that allows one to specify web 
server options as commands within config.ru, not only on the rackup 
command line or the comment line (#\) within config.ru. The need for 
this arises from new web server technologies like the ones typically 
used for Mongrel2 which need significantly more setup information than a 
simple Webrick or (legacy) Mongrel server.

Mongrel2 typically exchanges its web server requests and responses 
through *two* sockets, based on ZeroMQ, and these sockets can finally be 
Unix Domain Sockets which don’t waste the TCP socket address space. 
OTOH, in well-structured environments those IPC sockets need longer path 
names than a simple TCP port number, additionally it might be beneficial 
to use Ruby techniques to build up the IN and OUT IPC sockets based on 
some common pattern. Furthermore, Mongrel2 relies on a uuid setting for 
identifying sessions.

Setting all those options on the command line to a standalone rackup 
execution defeats its purpose, and setting them within the config.ru 
file inside the tiny littly comment line is ugly and cannot make use of 
Ruby constructs at all. So the idea was to let the newly created 
Rack::Builder object handle those options and hand it over to the 
calling process.

My change request, together with the necessary code and test changes, 
was rejected and closed right away by James with the comment

> config.ru is supposed to be portable and not bound to a particular server.

I wonder whether it’s James who doesn’t understand what I want, or 
whether it’s me who doesn’t understand what config.ru is supposed to be. 
I thought it is meant as a server configuration file: It

• defines which server technology to use (if there are multiple to 
choose from or if I want a specific solution),
• configures the used server, and
• defines which application and possible middleware to load.

The goal, as far as I got it, is to have the application and its setup 
bound together in a single configuration file, called config.ru. Sadly, 
the current syntax is only optimized for defining the application; the 
first two items on the list are handled via a clumsy comment line that 
gets longer the more options the web server requires for configuration.

So, can someone enlighten me, what’s the purpose of config.ru? Isn’t it 
supposed to carry the configuration for the web server as well?  Is it a 
bad idea to let Rack::Builder collect all these options within the 
config.ru body instead of the comment line?

– Matthias

Re: Purpose of config.ru (regarding server options), #245

[coolesting]

I think the config.ru is a interface for rack and let the rack to do
something what we want .

Whatever we do anything with the config.ru, we need to based on the
rack interface provided,  that is why we create a file config.ru for
rackup to start up the variety of web server, just my opinion.

2011/10/2 Matthias Wächter <matthias@waechter.wiz.at>:
> Hi,
>
> Recently, I forked rack and created a feature
> [https://github.com/rack/rack/pull/245] that allows one to specify web
> server options as commands within config.ru, not only on the rackup command
> line or the comment line (#\) within config.ru. The need for this arises
> from new web server technologies like the ones typically used for Mongrel2
> which need significantly more setup information than a simple Webrick or
> (legacy) Mongrel server.
>
> Mongrel2 typically exchanges its web server requests and responses through
> *two* sockets, based on ZeroMQ, and these sockets can finally be Unix Domain
> Sockets which don’t waste the TCP socket address space. OTOH, in
> well-structured environments those IPC sockets need longer path names than a
> simple TCP port number, additionally it might be beneficial to use Ruby
> techniques to build up the IN and OUT IPC sockets based on some common
> pattern. Furthermore, Mongrel2 relies on a uuid setting for identifying
> sessions.
>
> Setting all those options on the command line to a standalone rackup
> execution defeats its purpose, and setting them within the config.ru file
> inside the tiny littly comment line is ugly and cannot make use of Ruby
> constructs at all. So the idea was to let the newly created Rack::Builder
> object handle those options and hand it over to the calling process.
>
> My change request, together with the necessary code and test changes, was
> rejected and closed right away by James with the comment
>
>> config.ru is supposed to be portable and not bound to a particular server.
>
> I wonder whether it’s James who doesn’t understand what I want, or whether
> it’s me who doesn’t understand what config.ru is supposed to be. I thought
> it is meant as a server configuration file: It
>
> • defines which server technology to use (if there are multiple to choose
> from or if I want a specific solution),
> • configures the used server, and
> • defines which application and possible middleware to load.
>
> The goal, as far as I got it, is to have the application and its setup bound
> together in a single configuration file, called config.ru. Sadly, the
> current syntax is only optimized for defining the application; the first two
> items on the list are handled via a clumsy comment line that gets longer the
> more options the web server requires for configuration.
>
> So, can someone enlighten me, what’s the purpose of config.ru? Isn’t it
> supposed to carry the configuration for the web server as well?  Is it a bad
> idea to let Rack::Builder collect all these options within the config.ru
> body instead of the comment line?
>
> – Matthias
>

Re: Purpose of config.ru (regarding server options), #245

[James Tucker]

On Oct 2, 2011, at 4:25 AM, Matthias Wächter wrote:

> Hi,
> 
> Recently, I forked rack and created a feature [https://github.com/rack/rack/pull/245] that allows one to specify web server options as commands within config.ru, not only on the rackup command line or the comment line (#\) within config.ru. The need for this arises from new web server technologies like the ones typically used for Mongrel2 which need significantly more setup information than a simple Webrick or (legacy) Mongrel server.

Traditionally rack handler authors make the basics work using common standards (such as booting on port 9292), and then for enhanced configuration, they create their own bin file that supports extra options. See for example thin(1).

> Mongrel2 typically exchanges its web server requests and responses through *two* sockets, based on ZeroMQ, and these sockets can finally be Unix Domain Sockets which don’t waste the TCP socket address space. OTOH, in well-structured environments those IPC sockets need longer path names than a simple TCP port number, additionally it might be beneficial to use Ruby techniques to build up the IN and OUT IPC sockets based on some common pattern. Furthermore, Mongrel2 relies on a uuid setting for identifying sessions.
> 
> Setting all those options on the command line to a standalone rackup execution defeats its purpose, and setting them within the config.ru file inside the tiny littly comment line is ugly and cannot make use of Ruby constructs at all. So the idea was to let the newly created Rack::Builder object handle those options and hand it over to the calling process.

rackup is not specificaly intended for this use case.

Rack::Builder builds rack applications, it is not a generic server configuration system (which is far more complex, as you elude to above).

The intent of the rack project is to be a middleware between servers and web frameworks/applications. rackup is provided largely as a convenience and example, and would become significantly bloated if we were to try and support configuring all servers.

> My change request, together with the necessary code and test changes, was rejected and closed right away by James with the comment
> 
>> config.ru is supposed to be portable and not bound to a particular server.
> 
> I wonder whether it’s James who doesn’t understand what I want, or whether it’s me who doesn’t understand what config.ru is supposed to be. I thought it is meant as a server configuration file:

I understand what you want, but I do not want to maintain it. This can be perfectly serviced by your handler code carrying a bin file containing the specific requirements for your web server configuration.

> It
> 
> • defines which server technology to use (if there are multiple to choose from or if I want a specific solution),

This is not an intended feature of config.ru. If you add a shebang with arguments, that will only work on *some* platforms. Not all exec*(2) implementations support arguments. This approach is not portable.

> • configures the used server, and

There is no portable way to do this from inside config.ru.

> • defines which application and possible middleware to load.

This is all that config.ru is supposed to do.

> The goal, as far as I got it, is to have the application and its setup bound together in a single configuration file, called config.ru. Sadly, the current syntax is only optimized for defining the application; the first two items on the list are handled via a clumsy comment line that gets longer the more options the web server requires for configuration.
> 
> So, can someone enlighten me, what’s the purpose of config.ru? Isn’t it supposed to carry the configuration for the web server as well?  Is it a bad idea to let Rack::Builder collect all these options within the config.ru body instead of the comment line?

You should be able to run rackup(1) with a different -s flag and the config.ru will work (furthermore, if the user executes rackup(1) directly, then the shebang is entirely ignored) . Your proposal would lead to config.ru files that are not portable in this manner.

> 
> – Matthias

Re: Purpose of config.ru (regarding server options), #245

[Christian Neukirchen]

James Tucker <jftucker@gmail.com> writes:

> This is not an intended feature of config.ru. If you add a shebang
> with arguments, that will only work on *some* platforms. Not all
> exec*(2) implementations support arguments. This approach is not
> portable.

Early rackup actually had that, it seems it got lost in the movement to
rack/server (and it works nevermind whether the shebang ist parsed):

#!/usr/bin/env rackup
#\ -s thin -p 9393

(That was kinda inspired by
http://www.gnu.org/software/guile/manual/html_node/The-Meta-Switch.html)

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Purpose of config.ru (regarding server options), #245

[Matthias Wächter]

Hi James,

Thank you for the reply.

On 03.10.2011 01:20, James Tucker wrote:
> I understand what you want, but I do not want to maintain it.

Okay, let’s try it once more. I am really sorry for my initial pull request which might have caused 
your dislike of the patch as it included patches for another feature. I am really willing to enhance 
my git skills, so bear with me.

The actual change is simple and I think that you won’t have any trouble maintaining it. Remember, 
it’s coming with tests! :) I haven’t filed a new pull request, so please review the two commits I 
made on my branch, based on the latest rack/master branch.

https://github.com/typingArtist/rack/commit/a10b227c32c061fb18e42204bb6da07e237c80ad
https://github.com/typingArtist/rack/commit/0fd5b873de2096bb1b9e83e6f41fb5ed62ea8632

The changes do two things (not counting the changes for the test). First, I changed the eval() to 
not just return the app object – reduced from the Rack::Builder object via #to_app – but the full 
Rack::Builder object. As a side effect, this reduces the amount of code that runs within eval(). It 
allows to get the Builder object’s options to be returned and merged with the options given on the 
command line and on the special comment line. Second, I added the function which allows 
setting/adding options and retrieving them once the Builder object creation is done.

>> It
>> • defines which server technology to use (if there are multiple to choose from or if I want a specific solution),
>
> This is not an intended feature of config.ru. If you add a shebang with arguments, that will only work on *some* platforms. Not all exec*(2) implementations support arguments. This approach is not portable.

Nonono. I refer to the comment line starting as "#\" (yes, a backslash) which carries options – 
parsing these options is actually the first thing done in parse_file() after reading the .ru file. 
My patch is all about removing the need to use this #\ special comment line and allow Ruby 
constructs to be used instead.

>> • configures the used server, and
> There is no portable way to do this from inside config.ru.

Portable in which sense?

If I want to use rackup, I can use the #\ line or a whole lot of command line options to choose and 
configure the server. Why not allow those users to make those settings in a more Ruby-ish way?

>> • defines which application and possible middleware to load.
> This is all that config.ru is supposed to do.

Ouch. Then please remove rackup from rack.

> You should be able to run rackup(1) with a different -s flag and the config.ru will work …

As long as only portable options are entered to config.ru, the -s flag will work, certainly. At the 
moment, mongrel2 is special as it requires more and different options than a standard 
webrick/mongrel/thin server, i.e. just a port to run from.

> (furthermore, if the user executes rackup(1) directly, then the shebang is entirely ignored)

No, as said above, I am not referring to the standard shebang line but the one with the backslash.

> . Your proposal would lead to config.ru files that are not portable in this manner.

Yes and very much no. Users who want to use rackup and who want to setup their servers inside 
config.ru and know the limitations of the #\ line can do that already, but it comes at the price of 
having only one such line, special string escaping and just supporting strings. My patch allows for 
a much more elegant way of specifying these options within config.ru’s Ruby part, for those who want 
to use this feature – maybe it will lead to rackup being much more than an example binary in the future?

– Matthias

Re: Purpose of config.ru (regarding server options), #245

[Matthias Wächter]

Hi Christian,

On 03.10.2011 10:52, Christian Neukirchen wrote:
> Early rackup actually had that, it seems it got lost in the movement to
> rack/server (and it works nevermind whether the shebang ist parsed):
>
> #!/usr/bin/env rackup
> #\ -s thin -p 9393

By »lost«, you mean we should get rid of it altogether?

– Matthias

Re: Purpose of config.ru (regarding server options), #245

[Matthias Wächter]

Hi Rack community,

On 28.10.2011 23:01, Matthias Wächter wrote:
> https://github.com/typingArtist/rack/commit/a10b227c32c061fb18e42204bb6da07e237c80ad
> https://github.com/typingArtist/rack/commit/0fd5b873de2096bb1b9e83e6f41fb5ed62ea8632

Can I ask once more what’s wrong with this addition? It doesn’t hurt 
anyone using Rack now, and it removes the burden to write a separate 
binary just for calling rackup with the right options, like suggested in 
analogy to Thin. It is clear Ruby, no magic, no nothing.

Please, don’t ask me to maintain my own branch just for this stuff, please!

– Matthias