| Date | Commit message (Collapse) |
|---|
|
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*).
|
|
|