Stealing from Rack
There are lots of great stuff to steal from Ruby Rack. Today I cloned ContentLength middleware as well as updating ConditionalGET middleware. ContentLength middleware can actually be used like a "library" from Server who wants to make sure the content has a Content-Length.
I also implemented AccessLog and AccessLog::Timed middleware, which is like a mix of HTTP::Engine::Middleware::AccessLog and Rack::CommonLogger. We support Apache's log-format compatible format templates, and ::Timed subclass actually returns an iterator object that behaves like a filehandle to calculate the real body size (even if it's not array of chunks or real filehandle) and profiles the response serving time. This is disabled by default since that bypasses the same standalone server optimization like sendfile(2).
Middleware is now updated to make use of the new Plack::Util::headers, which is a cool way of doing Prototype OO.
my $hdrs = [ 'Content-Type' => 'text/plain' ];
my $h = Plack::Util::headers($hdr);
$h->set('Content-Type', 'text/html'); # this updates $hdrs as well
Rethinking PATH_INFO
We reread the CGI spec RFC 3875 and many web server implementations as well as the same discussions in Rack mailing list, and now think decoding PATH_INFO is the right behavior per the RFC (though Rack people appeared to decide otherwise by fixing Ruby servers behaviors).
Yes, we understand that it could be annoying when you can't tell the difference between /foo/bar%2fbaz and /foo/bar/baz but realistically there will be less issues with this than when your application have to decode everything and PATH_INFO behaving differently from CGI, which means the transition from CGI needs to be done a little more carefully. Or if the decoding is optional and specified as MAY, there could be a security hole with double decoding or encoding unless application developers are extremely careful to handle this.
We added a test to verify web servers need to decode PATH_INFO, and found some failures in many server environments, but we fixed it by patching HTTP::Parser::XS and its pure perl fallback. I also found a bug with HTTP::Request::AsCGI which was worked around to fix, or rather, mask Catalyst::Engine::CGI's bug. I reported the problem with their Engine::CGI anyway, which should be hopefully applied.
IO::Handle::Util
Yuval released the first dev release of IO::Handle::Util to CPAN. This would be a really useful module to use when your application or middleware want to return filehandle-like object instantly. This would also be a basis of his upcoming work on IO::Writer which enables you to do a non-blocking read in Event driven servers but fallback to the blocking read otherwise.
Sendfile and Standalone POST bugs
mala has been experimenting Sledge and Plack middleware and has found some bugs in anyevent server's AIO support where it's doing busy loop with EAGAIN and wrong size of data is returned to the client. This is now fixed by doing blocking mode which is the recommended way per IO::AIO docs.
Artur Bergman jumped in our IRC channel and toyed with Plack::Request to build basis for his coming REST server work around TheSchwartz. He spotted some problems with Plack::Request and bugs with Standalone server when you use curl's -D option to do multipart upload. Both of them were fixed now.
Plack::Test
Plack::Test has been a test suite to test a new Plack server implementation, but that was now renamed to Plack::Test::Suite, and Plack::Test has now become an unified interface to test PSGI application using the standard HTTP::Request and HTTP::Response, either using a mockHTTP runner or live HTTP Server with Plack::Loader. This is really useful.
Recent Comments