| Date | Commit message (Collapse) |
|---|
|
Also, some minor cleanups and branch refactoring.
|
|
Avoid using strcmp() since it could break badly if
Ruby ever stopped null-terminating strings C-style.
We're also freezing "http" as a global. Rack does not
explicitly permit nor deny this, and Mongrel has always
used frozen strings as hash values in other places.
|
|
Pass "https" to "rack.url_scheme" if the X-Forwarded-Proto
header matches "https". X-Forwarded-Proto is a semi-standard
header that Ruby frameworks seem to respect; so we use that.
We won't support ENV['HTTPS'] since that can only be set at
start time and some app servers supporting https also support
http.
Currently, "rack.url_scheme" only allows "http" and "https",
so we won't set anything else to avoid breaking Rack::Lint.
|
|
The build-time complexity was not worth the minor
performance improvement we could get for the average
case (and we can cut down the amount of comparisons
by putting frequent/required headers first).
|
|
"HTTP_BODY" could conflict with a "Body:" HTTP header if there
ever is one. Also, try to hide this body from the Rack
environment before @app is called since it is only used by
Unicorn internally.
|
|
This cuts the HttpParser interface down to #execute and #reset
method. HttpParser#execute will return true if it completes and
false if it is not. http->nread state is kept internally so we
don't have to keep track of it in Ruby; removing one parameter
from #execute.
HttpParser#reset is unchanged.
All errors are handled through exceptions anyways, so the
HttpParser#error? method stopped being useful.
Also added some more unit tests to the HttpParser since I know
some folks are (rightfully) uncomfortable with changing stable C
code. We now have tests for incremental parsing.
In summary, we have:
* more test cases
* less C code
* simpler interfaces
* small performance improvement
=> win \o/
|
|
Fix the logic in HttpParser up front so we don't have
to mess around with the following convoluted steps:
1. setting the HTTP_CONTENT_{LENGTH,TYPE} headers
2. reading the HTTP_CONTENT_{LENGTH,TYPE} headers again
3. setting the CONTENT_{LENGTH,TYPE} based on the
HTTP_-prefixed one
4. deleting the HTTP_CONTENT_{LENGTH,TYPE} headers
(since Rack doesn't like them)
1, 2, 3 were in the C code, 4 was in Ruby.
Now the logic is:
1. if CONTENT_{LENGTH,TYPE} headers are seen, don't prefix
with "HTTP_".
All the branch logic for the new code is done at init time, too
so there's no additional overhead in the HTTP parsing phase.
There's also no additional overhead of hash lookups in the extra
steps.
|
|
It's a CGI-ism and is not in the Rack spec, so don't bother.
|
|
There's no point in increasing method visibility since
it can cause conflicts with other libraries and reduces
the inlining opportunities the compiler can make.
|
|
|
|
Avoid conflicting with existing (and future) Mongrel installs in
case either changes. Of course, this also allows us more
freedom to experiment and break the API if needed...
However, I'm only planning on making minor changes to
remove the amount of C code we have to maintain and
possibly some minor performance improvements.
|