| Date | Commit message (Collapse) |
|---|
|
We don't need the Z constant anymore and inlining the header
writing gives a small overall performance improvement in
microbenchmarks. This also makes this method reentrant and
thread-safe for Rainbows as well.
|
|
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...)
|
|
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.
|
|
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 lets clients can pass through newly-invented status codes
that Rack does not know about.
|
|
Trying not to repeat ourselves. Unfortunately, Ruby 1.9 forces
us to actually care about encodings of arbitrary byte sequences.
|
|
Rack::Lint says they just have to work when to_i is
called on the status, so that's what we'll do.
|
|
Preventing needless duplication since Rack already has these
codes for us. Also, put the status codes in HttpResponse since
nothing else needs (or should need) them.
|
|
Simpler code on our end can be just a tick faster because
syscalls are still not as cheap as normal functions and this
still manages to play well with our lack of keepalive
support as closing the socket will flush it immediately.
|
|
Avoid creating garbage every time we lookup the status code
along with the message. Also, we can use global const arrays
for a little extra performance because we only write one-at-a
time
Looking at MRI 1.8, Array#join with an empty string argument is
slightly better because it skips an append for every iteration.
|
|
|
|
This avoids creating yet another binding. socket.syswrite()
should really only be called once since we use blocking sockets,
but just in case, we emulate a do+while loop with begin+while
|
|
Avoid creating new string objects and then discarding them right
away by stuffing non-constant but always-present headers into
the initial output.
|
|
There are weird (and possibly broken) clients out there that
require it despite being present in the first line of the
response. So be nice and accomodate them. Keep in mind that
the Rack SPEC explicitly forbids this header from being in the
headers returned by the Rack-based application; so we have to
always inject it ourselves and ignore it if the application
sets it.
|
|
This reworks error handling throughout the entire stack to be
more Ruby-ish. Exceptions are raised instead of forcing the
us to check return values.
If a client is sending us a bad request, we send a 400.
If unicorn or app breaks in an unexpected way, we'll
send a 500.
Both of these last-resort error responses are sent using
IO#write_nonblock to avoid tying Unicorn up longer than
necessary and all exceptions raised are ignored.
Sending a valid HTTP response back should reduce the chance of
us from being marked as down or broken by a load balancer.
Previously, some load balancers would mark us as down if we close
a socket without sending back a valid response; so make a best
effort to send one. If for some reason we cannot write a valid
response, we're still susceptible to being marked as down.
A successful HttpResponse.write() call will now close the socket
immediately (instead of doing it higher up the stack). This
ensures the errors will never get written to the socket on a
successful response.
|
|
The extra split slows things down a little as as it generates an
array with a new string value and adds an extra loop to iterate
through.
|
|
Rack uses a single newline character to represent multi-value
headers. Thus { 'Set-Cookie' => "foo=bar\nbar=foo" }
will get you:
Set-Cookie: foo=bar
Set-Cookie: bar=foo
While RFC2616 says you can combine headers as:
Set-Cookie: foo=bar,bar=foo
There are probably HTTP clients out there that don't handle
things correctly so don't bother...
Additionally, don't bother doing duplicate suppression anymore.
Just assume Rack or a higher layer knows what it's doing
regarding duplicates and we'll get a Hash most of the time
anyways.
|
|
The body could be an IO object that is closeable.
So make sure we close it if it can be closed to
avoid file descriptor leakage.
|
|
This also fixes a subtle bug in header generation when the +$,+
($OFS) variable is defined to something other than nil or ""
I'm really wondering what kind of drugs I was on (or _not_ on)
when I modified some of this from the Mongrel source.
|
|
Rack spec specifies #each must be defined, not #each_pair.
Hash#each_pair was marginally faster in Ruby 1.8, but in Ruby
1.9.1, Hash#each and Hash#each_pair are the same function.
|
|
Along with worker process management. This is nginx-style
inplace upgrading (I don't know of another web server that does
this). Basically we can preserve our opened listen sockets
across entire executable upgrades.
Signals:
USR2 - Sending USR2 to the master unicorn process will cause
it to exec a new master and keep the original workers running.
This is useful to validate that the new code changes took place
are valid and don't immediately die. Once the changes are
validated (manually), you may send QUIT to the original
master process to have it gracefully exit.
HUP - Sending this to the master will make it immediately exec
a new binary and cause the old workers to gracefully exit.
Use this if you're certain the latest changes to Unicorn (and
your app) are ready and don't need validating.
Unlike nginx, re-execing a new binary will pick up any and all
configuration changes. However listener sockets cannot be
removed when exec-ing; only added (for now).
I apologize for making such a big change in one commit, but once
I got the ability to replace the entire codebase while preserving
connections, it was too tempting to continue working.
So I wrote a large chunk of this while hitting
the unicorn-hello-world app with the following loop:
while curl -vSsfN http://0:8080; do date +%N; done
_Zero_ requests lost across multiple restarts.
|
|
Avoid needless userspace copies and craziness. We'll need to
handle EINTR since writes to sockets means stupid things like
this, but it's a small cost...
|
|
Just stuff what little logic we had for it into HttpResponse
since Rack takes care of the rest for us.
Put the HTTP_STATUS_HEADERS hash in HttpResponse since we're the
only user of it. Also, change HttpResponse.send to
HttpResponse.write to avoid overriding the default method.
|
|
The previous API was very flexible, but I don't think many
people really cared for it... We now repeatedly use the
same HeaderOut in each process since I completely don't
care for multithreading.
|
|
|
|
Regenerating headers constantly is a waste of time.
|
|
It's more GC-friendly to just use an array than to repeatedly
append short strings on top of each other. I also find StringIO
confusing...
|
|
Avoid conflicting with existing Mongrel libraries since
we'll be incompatible and break things w/o disrupting
Mongrel installations.
|