Date | Commit message (Collapse) |
|
Kinda sorta works, still some Markdown => HTML formatting issues
to work out but it gives the site a reasonably consistent look.
|
|
Additionally, force ourselves to verify our working tree against
$(VERSION) when doing releases because we don't want to screw
that up.
|
|
setup.rb users will now be able to install manpages under
man/man1 automatically, no solution for Rubygems users yet.
gzipped manpages are no longer created by default, either,
it's probably up to distros to do it.
|
|
It may not be portable to older versions of gzip
|
|
|
|
SCREAMING is already sufficient without *BOLDNESS*
|
|
`unicorn` tries to mimic `rackup` on the command-line to ease
adoption. `unicorn_rails` tries to be somewhat like `rackup` as
well, but then also tries to be consistent with `script/server`
resulting some amount of confusion with regard to the
-P/(--path|--pid) switch. Outright removal of these switches
will probably not happen any time soon because we have
command-lines inherited across processes, but we can stop
advertising them.
Since our (Unicorn) config file format is fortunately consistent
between Rails and !Rails, recommend the "pid" directive be used
instead.
User interfaces are really, really tough to get right...
|
|
|
|
* Manifest/CHANGELOG can be maintainance is painful.
I really hate having those in the source tree when
I have a version control system that already:
1) encourages me to make meaningful commits
2) is highly scriptable for generating manifests/changelogs
* hand-rolled gemspec allows more control for specifying
pre-release gem versions
* Less magic over what the `rubyforge` command does, being
able to spawn $VISUAL on changelogs/release notes and make
edits on them is nice.
Additionally I still strongly prefer GNU make over Rake for many
tasks since it offers better parallelization and some things are
easier *for me* in shell than Ruby.
|
|
No point in having those files under revision control or
repeating work to generate them.
|
|
When SIGHUP reloads the config, we didn't account for the case
where the listen socket was completely unspecified. Thus the
default listener (0.0.0.0:8080), did not get preserved and
re-injected into the config properly.
Note that relying on the default listen or specifying listeners
on the command-line means it's /practically/ impossible to
_unbind_ those listeners with a configuration file reload. We
also need to preserve the (unspecified) default listener across
upgrades that later result in SIGHUP, too; so the easiest way is
to inject the default listener into the command-line for
upgrades.
Many thanks to James Golick for reporting and helping me track
down the bug since this behavior is difficult to write reliable
automated tests for.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
|
This gives applications more rope to play with in case they have
any reasons for changing some values of the default constants.
Freezing strings for Hash assignments still speeds up MRI, so
we'll keep on doing that for now (and as long as MRI supports
frozen strings, I expect them to always be faster for Hashes
though I'd be very happy to be proven wrong...)
|
|
We may add support for the Gopher protocol in the future...
|
|
Just to ensure we handle HUP correctly since preload_app
changes the behavior of HUP handling a bit.
|
|
Only "unicorn(1)" is documented right now, but more will be
added.
Manpages are written Markdown since it's easy to write, easy to
read (in source form) and a widely-implemented format.
As of September 2009, pandoc is the only Markdown processor I
know of capable of turning Markdown into manpages. So despite
adding a dependency on Haskell (not yet very common these days)
for documentation, the features and performance of
pandoc+Markdown outweigh the drawbacks compared to other
lightweight markup systems.
|
|
"unicorn" (lower-case) refers to the executable script
|
|
We used to try it on every listener, but then rarely-used
listener ports used mainly for monitoring/debugging would have
accept() unnecessary called, getting unnecessarily expensive
inside the kernel.
|
|
|
|
This lets us avoid those ugly <user@UUID> faux email addresses
that "git svn" generates when "git svn" is not used with
--authors-file.
|
|
Sometimes I end up hacking on 10-row high terminals
and need more context :x
|
|
assert_frozen() should not be checking what type of
object it is, instead put an extra assertion in there
to ensure we have a string.
|
|
Note that Rubinius itself is still under heavy development, so
things we fix may break again. The pure-Ruby parts of Unicorn
don't even work properly on Rubinius.
|
|
Since empty values on one line can be a heuristic to determine
future lines are continuation lines (and a as a result, a
decently long header), pre-allocate a string buffer just in
case.
This is to workaround what appears to be bug in the Rubinius C
API, but it could be considered (intended) DWIM behavior, too...
|
|
Rubinius supports these functions as of
039091066244cfcf483310b86b5c4989aaa6302b
This allows the test_http_parser_ng.rb test to run under
Rubinius db612aa62cad9e5cc41a4a4be645642362029d20
|
|
Rubinius doesn't seem to set this by default
|
|
Rubinius has no rb_str_modify() function, it /may/
not need it.
|
|
Hope they have the LL2NUM macro (Rubinius does)
|
|
Rubinius does not support frozen objects, maybe other Rubies
lack support for it as well.
|
|
He contributed to Mongrel back in the day and isn't around Ruby
anymore, but at least get his preferred (lack-of) capitalization
right...
|
|
This can hide bugs in Rack applications/middleware. Most other
Rack handlers/servers seem to follow this route as well, so
this helps ensure broken things will break loudly and more
consistently across all Rack-enabled servers :)
|
|
This ensures any string literals that pop up in *our* code will
just be a bag of bytes. This shouldn't affect/fix/break
existing apps in most cases, but most constants will always have
the "correct" encoding (none!) to be consistent with HTTP/socket
expectations. Since this comment affects things only on a
per-source basis, it won't affect existing apps with the
exception of strings we pass to the Rack application.
This will eventually allow us to get rid of that Unicorn::Z
constant, too.
|
|
This hasn't been true since 3e9fe197d4daac14fa98addfcf9be3208c7b96b8
|
|
This probably doesn't affect anyone with HTTP/1.1, but
future versions of HTTP will use absolute URIs and maybe
we'll eventually get clients that (mistakenly) send us
Host: headers along with absolute URIs.
|
|
No need to add an extra check, even if it does avoid a
function call.
|
|
This should be more inline with Ruby standards/coding style
and probably more future-proof, as well.
|
|
This makes it easier for bug reporters to tell us what's
wrong in case line numbers change.
|
|
Just in case, it'll be easier to track down if bugs
pop up.
|
|
There's no need to use a goto here to avoid one level of
nesting.
|
|
This should make code easier to read and follow.
|
|
In case we modify our struct to not use bitflags, this should
make it easier to change the parser code. This also adds extra
clarification for how we track keepalive and why we only do it
for certain request methods.
|
|
These are similar to the macros found in MRI, and
can more easily allow us to swap out the bitflags
for real struct members...
|
|
Avoid a negative conditional in the process and having an
explicit else in there makes this piece easier to track.
Also explain /why/ the Host: header can get ignored.
|
|
Just pass the http_parser struct pointer when checking for
invalid headers in the trailer. The compiler should be smart
enough to inline and not relookup the flags. This avoids having
to worry about the flags being signed or not (they should never
be) and also makes it easier to maintain if we move away from
using bitfields.
|
|
|
|
|
|
Avoid potential issues that can arise from logging any weird
characters that may not be supported in the current encoding.
|
|
HTTP/0.9 GET requests expect responses without headers. Some
weird applications/tools still use the ancient HTTP/0.9
protocol for weird reasons, so we'll support them.
ref: rfc 1945, section 4.1
|
|
This method determines if there are headers in the request.
Simple HTTP/0.9 requests did not have headers in the request
(and our responses we make should not have them, either).
|
|
And it'll default to HTTP/0.9 if HTTP_VERSION is not specified
(as version-less HTTP requests imply HTTP/0.9.
|
|
Followup to commit 7f74a16406c92c4362ac20af4ccb8bc821cf978b,
we want to ensure error messages do not get swallowed up into
/dev/null when daemonizing; so we defer the default redirects
to "/dev/null" to as late as possible.
|