Results tagged “Catalyst”

A midwinter box bike ride
Recently I've been reviewing how various Perl frameworks and modules generate HTTP headers. After reviewing several approaches, it's clear that there are two major camps: those which put the response headers in a specific order and those which don't. Surely one approach or the other would seem like it would be more spec-compliant, but RFC 2616 provides [conflicting guidance on this point]( The bottom line is that spec says that *"the order in which header fields with differing field names are received is not significant"*. But then it goes on to say that it is a "good practice" (and it puts "good practice" in quotes) to order the headers a particular way. So, without strict guidance from the spec about the importance of header ordering, it would be interesting to know if header order caused a problem in practice. The [Plack::Middleware::RearrangeHeaders]( documentation suggests there is some benefit to strict header ordering: *"to work around buggy clients like very old MSIE or broken HTTP proxy servers"* You might wonder what the big deal is-- why not just stick to the "good practice" recommendation all the time? The difference can be seen in the benchmarks provided by [HTTP::Headers::Fast]( By ignoring the good-practice header order, an alternate implementation was able to speed-up header generation to be about twice as fast. Considering that a web-app needs to generate a header on every single request, making header generation smaller and faster is potentially a tangible win, while also still being spec-compliant.
This weekend I spent some quality time with HTTP Cookie Specs ( [RFC 2109]( and [RFC 2695]( ), and looked closely how at the cookie parsing and handling is done in three Perl frameworks: [Titanium](, [Catalyst]( and [Mojo]( Titanium uses [CGI::Cookie]( by default, while Catalyst uses [CGI::Simple::Cookie]( and Mojo uses built-in modules including [Mojo::Cookie::Request]( I'll look at these solutions through the filters of Standards, Security, and Convenience. ## Standards: Max-Age, Set-Cookie2 and commas Max-Age is cookie attribute which gives the expiration time as a relative value. This is considered a more secure replacement for the "Expires" header, which gives the time as an absolute value, making it vulnerable to clock skew on the user's systems. and Mojo support it, but CGI::Simple does not. This is potentially an issue for Catalyst users, if they believe they have Max-Age support because the documentation refers them to CGI::Cookie, but they actually don't because they are using CGI::Simple::Cookie. Set-Cookie2 is a standard from 2000 to replace Set-Cookie, which became a standard in 1997. Mojo is the only of the three that supports it. However, Set-Cookie2 [never caught on]( Firefox 3 doesn't even support it, and neither does IE 6. Still, I like the idea of deciding for myself about supporting new standards, rather than having tools that only support older standards. Mojo wins here. The RFCs say that servers should accept a comma as well as semicolon between cookie values. and Mojo comply here, CGI::Simple does not. (I've submitted a [patch to address this](, along with a few other places I felt CGI::Simple cookie parsing lagged ## Security CGI::Simple cookies are potentially less secure because they lack "Max-Age" support. Mojo's cookie implementation appears to be vulnerable to an injection attack where untrusted data in a cookie value can write a new HTTP body. I have notified the developers of my findings there. and CGI::Simple both avoid the injection attack by URI-encoding the cookie values, (a spec-compliant solution). ## Convenience and CGI::Simple share several convenient user interface features which Mojo currently lacks. They allow you to set multiple-values for a single cookie, including setting a hashref. They also provide a convenient shorthand for giving expiration times, like "+10m" for "10 months in the future". Mojo lacks these features. If you have a Catalyst app that uses the multiple-values features, a port to Mojo could mean a painful cookie transition, since Mojo does not have a built-in understanding of the format uses to store cookie values. (This detail is not dictated by the cookie spec so both value formats are "spec compliant"). ## Conclusions Sebastian Riedel, the Mojo author, promotes Mojo as being focused on standards. From my findings here, I have to say that I agree that Mojo is a leader here, currently at the expense of a potentially serious security issue, and lacking some usability features that the others offer. CGI::Simple has a reputation but being a lighter and better enigeneered version of Certainly the overall the design and focus of CGI::Simple is an improvement. But the reality is that CGI::Simple was forked from in 2001. has received many improvements since then including improved cookie handling, like adding support for "Max-Age". However, CGI::Simple doesn't seem to make a point of tracking and merging improvements that originate in CGI::Simple is perhaps more like a lighter, tighter alternative to as it existed several years ago. The mature-but-maligned comes out fairing the best for cooking handling in my opinion. It did not have any of the potential security issues I found with the other two, and it has a range of convenient methods for cookie access. But as a final note, I encourage to you check with the specific projects for the most current information, as some of the deficiencies I found here may already be addressed.
Grover's recumbent, side view There's a lot of trash talk among professional web programmers regarding using vanilla CGI, like Stevan Little's [recent comment]( *"There is no excuse to still use vanilla CGI as it is simply just a waste of resources"*. As an experienced professional website developer myself, I find that CGI has its place. First, let's recap what we're talking about.
Mojo Perl web framework logo Here's my take on [Mojo]( 0.8.7, a new web framework for Perl. The primary author of Mojo, Sebastian Riedel was once as a primary contributor to Catalyst. There are clearly some similarities, and it's easy for me to see Mojo as an evolution of Catalyst. One major difference with Catalyst sparked my interest in Mojo. Catalyst now depends on Moose among other things, with a very long overall dependency change. How long? I downloaded Catalyst 5.8 along with all of it's non-core Perl module dependencies. The result was over **250** modules, not counting the Catalyst modules themselves, or anything in the Test::* name space. Bleh. *What to see for yourself? Get my "self-contained" patch out of the local::lib tracker and run the following. It will install Catalyst and all it non-core dependencies into a "Catalyst" folder. Be aware, this could take half an hour or more... (The TinyURL points a Catalyst 5.8 tarball)* perl -MCPAN -Mlocal::lib=--self-contained,Catalyst \ -e 'install ""' Leaning on dependencies can be a great thing. It works well when you are able to outsource part of your needs to an external module that is already well written, documentation and tested. I'm sure there's some of that happening in the Catalyst dependency chain. But there's also a good deal of duplication, as different authors solve things different ways. For example:, Sub::Exporter and Moose::Exporter all serve the same function, and are dependencies somewhere along the way. Class::Accessor::Fast competes with MooseX::Emulate::Class::Accessor::Fast. And this is where a long dependency chain can start to look and feel like bloat, and it can be difficult to overcome if the owners of the dependencies don't share the projects preferences about how to export subroutines or build accessors. It could perhaps be said though that Mojo suffers from re-using too little. Mojo::Base is yet-another accessor-generation solution, like Class::Accessor. The potential I see in Mojo is the summed up in the following: * No dependency chain, for less complexity and easy deployment * Built-in support for several backends, for portability * A rewrite of HTTP request and response objects, as a sanely designed evolution of what has been used for * No ties to a specific framework design beneath the server/response-request object layer, for flexibility and potential code sharing between frameworks based on it. It is this last item that has allowed me to ignore the bundled Mojolicious framework for this review-- It's not required for use with Mojo and could use it's own review. Overall, I feel positive about the Mojo project, although I have no current plans to quit developing with [Titanium]( projects myself. In theory, they could be used together. Mojo could provide the backend-server support and query object, and CGI::Application could run inside the Mojo handler() in much the same way CGI::Application apps can run in a mod_perl handler. Now, CGI::Application can already run under various servers and with different query objects, so whether or not you'd actually want to use CGI::Application with Mojo is left up to the reader. I don't recommend using Mojo yet-- it needs more documentation and tests for my taste. It's Mojo's clean, scalable and extensible design that make it a project worth following. I'll be keeping my eye on Mojo. *This post is being [discussed on](*