Date | Commit message (Collapse) |
|
1.8 did not support my preferred way of writing hashes
with symbol keys.
|
|
Rack::Lint::ErrorWrapper forbids the "<<" method. This
fallback only comes into play when no log destination
(via :logger or :path) is specified and is rarely an
issue in real setups.
|
|
The use of Rack::BodyProxy#method_missing causes failures
under mainline Ruby 1.9.2 and 1.9.1, but not 1.9.3. This
test case exists to document this (now-fixed) bug for users
stuck on older Rubies.
On a side note, our usage of rb_iterate() should be rewritten
to use rb_block_call() as rb_iterate() is deprecated in 1.9.
A Ruby 1.9.2-p290 user privately reported this issue.
|
|
These values are untrusted, so if any client sends them to us
we must escape them.
|
|
This matches the behavior of nginx 1.0.9
|
|
Could be useful for some folks.
|
|
This doesn't apply to people that use strftime()-formats,
but that's a minority.
|
|
This appeared in nginx 0.9.6
|
|
This allows using:
use Clogger, :format => :Rack_1_0
Instead of:
use Clogger, :format => Clogger::Format::Rack_1_0
|
|
Since we delegated response_to?, we also need to delegate
method_missing to the response body in case there are
non-standard methods defined outside of Rack.
|
|
This optimization is used by Rainbows! to pass IO objects
to the response body.
|
|
nginx doesn't have this, only time_local, but we do
|
|
In case some folks need to use insanely long time formats,
we'll support them.
|
|
We can just make Clogger#respond_to? smarter and forward
everything except :close to the body we're proxying.
|
|
We'll be getting rid of an unnecessary wrapper class
|
|
It was totally broken but nobody uses uses it, so it
went unnoticed since the beginning of time.
|
|
This lets us use CLOCK_MONOTONIC so we are not affected by
system clock changes.
We still convert to microseconds instead of nanoseconds for
(pure)-Ruby 1.8 code compatibility. There is also little need
for nanosecond timer resolution in log files (microsecond is not
needed, even).
|
|
This lessens confusion for people configuring Clogger in
config.ru, since "File" could be mistaken for Rack::File
and "::File" needs to be specified.
|
|
Certain configurations of Rainbows! (and Zbatery) are able to
use the return value of body.to_path to serve static files
more efficiently.
This also allows middleware like Rack::Contrib::Sendfile to
work properly higher up the stack, too.
|
|
We no longer write the log out at the end of the body.each call.
This is a behavioral change, but fortunately all Rack servers
I've seen call body.close inside an ensure.
This allows us to later pass along the "to_path" method
and not rely on "each" to write the log.
|
|
|
|
They're slightly faster when we know a number is small enough
to be a FIXNUM.
|
|
The optional C extension leaked memory due to improper use of
the Ruby API, causing duplicated objects to never be garbage
collected.
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.
|
|
Clogger may set this value independently of "rack.multithread"
since Actor/Fiber-based servers may have multiple instances of
Clogger wrapping different response bodies and yet be
incompatible with "rack.multithread"
|
|
It's too crazy to have to special case for frozen response
constants. 3-element arrays are cheap under Ruby 1.9 anyways.
|
|
Rack::Lint will be relaxed in the next version to allow
subclasses of String and Hash objects, so ensure we're
good to go when the next version of Rack hits.
|
|
Since the wrapped Clogger object always responds to
close, we cannot blindly delegate the close method to
the body without ensuring it can be closed. So ensure
that it can be closed before attempting to close it,
all return values and errors are trapped and returned.
Reported-by: Iñaki Baz Castillo
|
|
No point in having extra code to do case-insensitive lookups,
especially since the HeaderHash implementation is already in
wide use and will only get faster as time goes by.
|
|
This allows overriding the default of "\n". Behavior remains
similar to IO#puts, the :ORS (output record separator) is
appended iff the format doesn't already end with that string.
|
|
Userspace buffering defaults are dangerous as the Ruby default
IO objects do not do line-aware buffering. This makes the
README examples with File.open much safer to use out-of-the-box
for users of the pure-Ruby version. For users on the MRI C
extension logging to regular files, this should not have any
effect as we've optimized those to do unbuffered write(2)
syscalls anyways.
|
|
Since Rack doesn't allow the HTTP_CONTENT_{LENGTH,TYPE} headers,
alias attempts to use those to the non-"HTTP_"-prefixed
equivalents to avoid confusion on the user side (nginx also does
this).
|
|
Since the HTTP_CONTENT_LENGTH and HTTP_CONTENT_TYPE variables
are not allowed by Rack, we need to allow access to the CGI
variables instead.
|
|
Accessing "REQUEST_METHOD" in the Rack env should be doable as a
CGI-ish variable. Thanks to Iñaki Baz Castillo for spotting the
issue and reporting it to me.
|
|
Back in HTTP/0.9 days (before it was called HTTP/0.9),
"GET /uri/goes/here\r\n" was a valid HTTP request.
See rfc 1945, section 4.1 for details on this ancient
"Simple-Request" scheme used by HTTP/0.9 clients.
|
|
The pure variant was using lower-case output instead
of upper case, the ext variant was actually fine in this
case. This is for nginx output format compatibility.
|
|
We're not Rack::Lint, but we still need to take steps to
avoid segfaulting if we host non-Rack::Lint-compliant
applications.
This also updates the pure variant to fail on bad applications,
too.
|
|
Some misbehaved apps can do this to us, and we don't want
the C extension to segfault when this happens.
|
|
This was documented in the README but never implemented. Some
popular web servers set REQUEST_URI even though it's not
required by Rack, so allow this variable to be used if possible.
As a side effect, it is also less likely to be modified by
certain handlers (*cough*Rails::Rack::Static*cough*).
|
|
|