Date | Commit message (Collapse) |
|
"clogger_ext" is no longer a separate gem, but merged into the
"clogger" gem itself. The installation should automatically
detect compatible versions of Ruby and only build the C
extension for MRI 1.8/1.9.
Rack::Utils::HeaderHash is now used for $sent_http_* variable
lookups instead of a hand-rolled solution. HeaderHash objects
should be reusable in Rack soon to avoid the penalty of
recreating them repeatedly in middlewares and hopefully
more-widely used as a result.
Underlying logger objects are sync=true for safety reasons.
This has always been the case for the C extension version
when writing to regular files.
Other small changes include more CGI variables and the :ORS
(output record separator) option added (default: "\n").
|
|
It's expensive to create if not needed, and no current released
version of Rack has my proposed optimizations for it yet...
|
|
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.
|
|
$auth_type, $gateway_interface, $server_software,
$path_translated are all supported now.
|
|
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.
|
|
This is useful for testing the pure Ruby version in case
clogger_ext is already installed on your system.
|
|
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*).
|
|
|