Date | Commit message (Collapse) |
|
|
|
Ugh, one day I'll clean them up, one day...
|
|
Just in case we have people that don't use DNS, we can support
folks who enter ugly IPv6 addresses...
IPv6 uses brackets around the address to avoid confusing
the colons used in the address with the colon used to denote
the TCP port number in URIs.
|
|
But allows small optimizations to be made to avoid
constant/instance variable lookups later :)
|
|
The first value of X-Forwarded-Proto in rack.url_scheme should
be used as it can be chained. This header can be set multiple
times via different proxies in the chain, but consider the first
one to be valid.
Additionally, respect X-Forwarded-SSL as it may be passed with
the "on" flag instead of X-Forwarded-Proto.
ref: rack commit 85ca454e6143a3081d90e4546ccad602a4c3ad2e
and 35bb5ba6746b5d346de9202c004cc926039650c7
|
|
Yes, this means even POST/PUT bodies may be kept alive,
but only if the body (and trailers) are fully-consumed.
|
|
Non-MRI runtimes (like Rubinius) may implement garbage
collection very differently than MRI.
|
|
...than "test ?r" and "test ?w"
Not everybody comes from a Unix shell programming background,
even though they *should* ;)
|
|
This is allowed by RFC 2616, section 2.2, where spaces and
horizontal tabs are counted as linear white space and linear
white space (not just regular spaces) may prefix field-values
(section 4.2).
This has _not_ been a real issue in ~4 years of using this
parser (starting with Mongrel) with clients in the wild.
Thanks to IƱaki Baz Castillo for pointing this out.
|
|
First off, this memory leak DOES NOT affect Unicorn itself.
Unicorn allocates the HttpParser once and always reuses it
in every sequential request.
This leak affects applications which repeatedly allocate a new
HTTP parser. Thus this bug affects _all_ deployments of
Rainbows! and Zbatery. These servers allocate a new parser for
every client connection.
I misread the Data_Make_Struct/Data_Wrap_Struct documentation
and ended up passing NULL as the "free" argument instead of -1,
causing the memory to never be freed.
From README.EXT in the MRI source which I misread:
> The free argument is the function to free the pointer
> allocation. If this is -1, the pointer will be just freed.
> The functions mark and free will be called from garbage
> collector.
|
|
This is not explicitly specified or listed as an example in in
rfc2616. However, rfc2616 section 3.2.1 defers to rfc2396[1]
for the definition of absolute URIs, so the userinfo component
should be allowable, even if it does not make any sense.
In the real world, previous versions of Mongrel used URI.parse()
and thus allowed userinfo, so we also have precedence to allow
userinfo to be compatible *in case* our interpretation of the
RFCs is incorrect. This change is unfortunately needed because
*occasionally* real clients rely on them.
Reported-by: Scott Chacon
[1] rfc3986 obsoletes rfc2396, but also includes userinfo
|
|
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.
|
|
And it'll default to HTTP/0.9 if HTTP_VERSION is not specified
(as version-less HTTP requests imply HTTP/0.9.
|
|
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.
|
|
ab still sends this with HTTP/1.0 requests, which is
unfortunate, but synthetic benchmarks are good for marketing
purposes!
|
|
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 should be more robust, faster and easier to deal
with than the ugly proof-of-concept regexp-based ones.
|
|
No point in making syscalls to deal with empty bodies.
Reinstate usage of the NULL_IO object which allows us
to avoid allocating new objects.
|
|
|
|
They aren't common, but apparently there exist
URLs with them, so we'll support them.
|
|
We now parse the scheme, host and port from Absolute URIs and
ignore them if the equivalents are specified in the other
headers.
|
|
This means "Host: foo-bar:" (trailing colon) will assume
server_port is 80, not a blank string.
|
|
|
|
It's part of the HTTP/1.1 (rfc2616), so we might as well
handle it in there and set PATH_INFO while we're at it.
Also, make "OPTIONS *" test not fail Rack::Lint
|
|
This was back when I did s/mongrel/Unicorn/g
on the sources.
|
|
"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/
|
|
It's a CGI-ism and is not in the Rack spec, so don't bother.
|
|
Avoid conflicting with existing Mongrel libraries since
we'll be incompatible and break things w/o disrupting
Mongrel installations.
|
|
|
|
This seems to have gotten accidentally dropped during a merge: r1020
Some broken web browsers don't properly escape ", <, and > characters
in URLs, however these URLs to occasionally legitimate and sometimes
show up.
This patch was submitted by Eden Li here:
http://rubyforge.org/pipermail/mongrel-users/2006-October/001845.html
This patch was accepted by Zed Shaw here:
http://rubyforge.org/pipermail/mongrel-users/2006-October/001847.html
git-svn-id: svn+ssh://rubyforge.org/var/svn/mongrel/trunk@1031 19e92222-5c0b-0410-8929-a290d50e31e9
|
|
ref: http://thread.gmane.org/gmane.comp.lang.ruby.mongrel.devel/37/focus=45
We got 'pen' mixed up with 'pound' in that thread but the gist
of it is still relevant: these nasty headers are irrelevant.
'pound' is the only thing that's known to send these nasty
headers and I (Eric Wong) don't consider pound relevant at all.
git-svn-id: svn+ssh://rubyforge.org/var/svn/mongrel/trunk@1030 19e92222-5c0b-0410-8929-a290d50e31e9
|
|
Apply fix for Ragel 6 (Eric Wong, Ry Dahl).
Two tests fail with the new parser (1 failed with the old parser). Needs investigation.
Close #12 (mongrel_rails send_signal leaves a filehandle open until gc).
Close #14 (mongrel_rails command line option --num-procs does not change the max number of procs).
Close #15 (mongrel squashes helpful exception in register method).
Close #16, XXX needs audit! (CGIWrapper "options" attr_reader has no corresponding @options variable).
Close #20 (Mongrel doesn't erase temporary files during it's operation on windows).
Close #19, XXX needs audit! (HttpResponse#reset does not properly reset HeaderOut).
Close #22 (gem_plugin should load gems from Gem.path not Gem.dir).
Close #23 (mongrel_cluster's mongrel_rails configuration option isn't fully respected).
If I had git, being offline wouldn't have resulted in one massive commit.
git-svn-id: svn+ssh://rubyforge.org/var/svn/mongrel/branches/stable_1-2@995 19e92222-5c0b-0410-8929-a290d50e31e9
|