| Date | Commit message (Collapse) |
|---|
|
Existing license terms (Ruby-specific) and GPLv2 remain
in place, but GPLv3 is preferred as it helps with
distribution of AGPLv3 code and is explicitly compatible
with Apache License (v2.0).
Many more reasons are documented by the FSF:
https://www.gnu.org/licenses/quick-guide-gplv3.html
http://gplv3.fsf.org/rms-why.html
ref: http://thread.gmane.org/gmane.comp.lang.ruby.unicorn.general/933
|
|
It may return the previous second
|
|
Rack::Lint already stops apps from using it. If a developer
insists on it, then users who inspect their HTTP headers can
point and laugh at them for not using Rack::Lint!
|
|
Response bodies may capture the block passed to each
and save it for body.close, so don't close the socket
before we have a chance to call body.close
|
|
No need to preserve the response tuplet if we're just
going to unpack it eventually.
|
|
This can return a static string and be significantly
faster as it reduces object allocations and Ruby method
calls for the fastest websites that serve thousands of
requests a second.
It assumes the Ruby runtime is single-threaded, but that
is the case of Ruby 1.8 and 1.9 and also what Unicorn
is all about. This change is safe for Rainbows! under 1.8
and 1.9.
|
|
It's a minor garbage reduction, but nobody uses "$,", and
if they did, they'd break things in the Ruby standard library
as well as Rack, so let anybody who uses "$," shoot themselves
in the foot.
|
|
There's no need for a response class or object since Rack just
uses an array as the response. So use a procedural style which
allows for easier understanding.
We shall also support keepalive/pipelining in the future, too.
|
|
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 lets clients can pass through newly-invented status codes
that Rack does not know about.
|
|
Must have multiple headers to test this effectively
|
|
Rack::Lint says they just have to work when to_i is
called on the status, so that's what we'll do.
|
|
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.
|
|
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 is in the Rack specification and a good idea. Remind
ourselves to prevent file descriptor or other resource leaks in
case the body is not an Array.
|
|
We always close the socket immediately after a
successful write for two reasons:
1) To prevent error responses from being rewritten.
If we throw an exception in our request/app/response
chain, we'll attempt to write an HTTP 400/500 response
out if the socket is open. No way to write to
an open socket.
2) To uncork the socket if TCP_CORK is enabled (Linux)
ASAP. This should be a tick faster than waiting
to go back up the stack and close it there.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Avoid conflicting with existing Mongrel libraries since
we'll be incompatible and break things w/o disrupting
Mongrel installations.
|
|
|
|
|
|
They are mainly unit tests anyway; we can clean them up more moving forward.
git-svn-id: svn+ssh://rubyforge.org/var/svn/mongrel/branches/stable_1-1@973 19e92222-5c0b-0410-8929-a290d50e31e9
|