Date | Commit message (Collapse) |
|
Leaving the EOFError exception as-is bad because most
applications/frameworks run an application-wide exception
handler to pretty-print and/or log the exception with a huge
backtrace.
Since there's absolutely nothing we can do in the server-side
app to deal with clients prematurely shutting down, having a
backtrace does not make sense. Having a backtrace can even be
harmful since it creates unnecessary noise for application
engineers monitoring or tracking down real bugs.
|
|
Subclass off the core File class so we don't have to
worry about #size being defined. This will mainly
be useful to Rainbows! but allows us to simplify
our TeeInput implementation a little, too.
|
|
The relative working_directory test runs so quickly
that the master may not even have signal handlers
setup by the time we're done with it. The proper
way would be to not start workers until the master
is ready, but that breaks some test cases horribly.
|
|
Make sure we're completely resumable no matter how
idiotic clients are.
|
|
This allows clients to trickle headers and trailers. While
Unicorn itself does not support slow clients for many reasons,
this affects servers that depend on our parser like Rainbows!.
This actually does affect Unicorn when handling trailers, but
HTTP trailers are very ever rarely used in requests.
Fortunately this stupid bug does not seem able to trigger
out-of-bounds conditions.
|
|
Prevent ourselves from breaking things in case applications
start depending on this.
|
|
It makes more sense this way since users usually expect config
file directives to be order-independent.
|
|
This basically a prettier way of saying:
Dir.chdir(Unicorn::HttpServer::START_CTX[:cwd] = path)
In the config file. Unfortunately, this is configuration
directive where order matters and you should specify it
before any other path[1] directives if you're using relative
paths (relative paths are not recommended anyways)
[1] pid, stderr_path, stdout_path
|
|
Just write bytes to the file instead and track its
size increase instead of its mode. As of now all
the unit tests pass under FreeBSD 7.2.
|
|
Not documented on FreeBSD 7.2, but it seems to happen there
and searching around, it seems to happen on other systems,
too...
|
|
IPv4 addresses in the format of: "^[[:digit:]]+:[[:digit:]]+$"
isn't very portable..
|
|
We modified TeeInput to have read-in-full semantics in most
situations to suit existing apps and libraries (like Rails) that
don't check for and handle partial reads correctly.
The read-in-full semantics are needed by Rails because of this:
https://rails.lighthouseapp.com/projects/8994/tickets/3343
|
|
Checking for addr to match the DEFAULT_HOST constant
is wrong since having only 127.0.0.1:8080 will still
prevent 0.0.0.0:8080 from being bound.
|
|
:delay may be a Float to represent fractional seconds.
|
|
There's always been a small window of opportunity for a script
to do File.read(pid).to_i would cause File.read() to read an
empty file and return "". This closes that window while
hopefully retaining backwards compatibility...
We've always checked for dirname(pid) writability in
Configurator, so we can safely write to a temporary file in the
intended directory and then atomically rename() it to the
destination path.
|
|
Since Unicorn config files are written in Ruby, setting
RAILS_RELATIVE_URL_ROOT should be possible (and even encouraged)
in the config file if it is done at all.
|
|
We don't want to accidentally kill every process in the
process group.
|
|
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>
|
|
Just to ensure we handle HUP correctly since preload_app
changes the behavior of HUP handling a bit.
|
|
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 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.
|
|
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.
|
|
SERVER_PROTOCOL is actually defined as "HTTP/1.1 even though it
should not be for HTTP/0.9 responses.
|
|
HTTP/0.9 only supports GET requests and didn't require a
version number in the request line. Additionally, only
a single CRLF was required.
Note: we don't correctly generate HTTP/0.9 responses, yet.
|
|
While I still consider pound to be irrelevant, but I still
sometimes get hand-crafted HTTP requests that come in with
multiline headers. Since these are part of the HTTP specs and
not difficult to support, we might as well support them for
the sake of completeness.
|
|
Rack is autoload-based and so are we.
|
|
ab still sends this with HTTP/1.0 requests, which is
unfortunate, but synthetic benchmarks are good for marketing
purposes!
|
|
This lets clients can pass through newly-invented status codes
that Rack does not know about.
|
|
It's not worth the effort to keep the internal API consistent
between non-bugfix versions.
|
|
TeeInput being needed is now (once again) an uncommon code path
so there's no point in relying on global constants. While we're
at it, allow StringIO to be used in the presence of small
inputs; too.
|
|
This makes a noticeable difference on light GET/HEAD requests.
Heck, even the tests run a few seconds faster.
|
|
This should be used to detect if a request can really handle
keepalives and pipelining. Currently, the rules are:
1. MUST be a GET or HEAD request
2. MUST be HTTP/1.1
3. MUST NOT have "Connection: close" set
This also reduces the amount of garbage we create by
globalizing constants and using them whenever possible.
|
|
This method is strictly a filter, it does no I/O so "read"
is not an appropriate name to give it.
|
|
The normal at_exit handlers can't work here
|
|
Otherwise Ruby could get confused and not be able to reap the
process correctly (and thus wait a long time for timeout).
|
|
Otherwise they might be picked up by the GC during the
other tests (exposed by Ruby 1.9.1-p243).
|
|
Since Rack requires a Hash object, this is joined in in
accordance with rfc2616, section 4.2[1]. Of course, it's up to
the framework or application to handle such requests.
I could optimize this to avoid creating a single garbage
String object, but I don't think it's common enough to
worry about...
[1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
|
|
Just in case clients decide to get cute.
|
|
We're bound by the maximum value of off_t when handling
input bodies (we need to buffer to disk). Also ensure
we stop bad clients that send us unparseable lengths.
|
|
This should be more robust, faster and easier to deal
with than the ugly proof-of-concept regexp-based ones.
|
|
Our current TrailerParser is liberal and does not require it,
but the to-be-activated Ragel one is not.
|
|
|
|
|
|
test/test_helper doesn't seem to be required correctly anymore,
since we know our own module/test names don't conflict, just
fix RUBYLIB to include $(test_prefix)
With test_util.rb, using #reopen with Tempfile objects seems
prone to the objects being closed. Not completely sure what is
going on but I'll just sidestep around it since I've stopped
trusting Tempfile by now...
|
|
This simplifies chunked_reader substantially with a slight
increase in tee_input complexity. This is beneficial because
chunked_reader is more complex to begin with and more likely
to experience correctness issues.
|
|
We couldn't do proper namespacing for the C module so there was
a potential conflict with Init_http11() in Mongrel. This was
needed because Mongrel's HTTP parser could be used in some
applications and we may be unfortunate enough need to support
them.
|
|
There's a small memory reduction to be had when forking
oodles of processes and the Perl hacker in me still
gets confused into thinking those are arrays...
|