The Advisory Boar

By Abhijit Menon-Sen <>

Mojolicious and X-Powered-By

A few days ago, I discovered that Mojolicious::Plugin::PoweredBy is enabled by default, and adds an "X-Powered-By: Mojolicious (Perl)" header to all HTTP responses. Although I can change the value of the header, there is no way to suppress it (e.g. by setting the value to undef). Since X-headers are meant for private experiments, and should not be exposed to the Internet (never mind how many people do it anyway), I thought this was poor behaviour.

The solution was to bundle an empty PoweredBy plugin with my app:

package Mojolicious::Plugin::PoweredBy;

use base 'Mojolicious::Plugin';

sub register {
}

1;

I brought this up in #mojo on IRC, suggesting tactfully that the plugin should either not be enabled by default, or be easier to disable (when what I really wanted was to suggest it be removed entirely). The Mojo author disagreed, and said that nobody would enable it if it wasn't enabled by default (which is quite true, and to me suggests that it should not exist at all), and that it was "advertising" for Mojo.

It may be advertising, but I'm not sure it sends the right message.

Trying out Mojolicious

A brief account of how I came to select Mojolicious as my Perl framework of choice to develop web applications. I've been a happy user for years now.

Read more…

ExtUtils::MakeMaker and the case of the C++ library

I have been working on an XS interface to a C++ library comprising three namespaces split across several source files. I wanted to keep and build these files in their own subdirectory, and have only my .xs file at the top level. This was surprisingly hard to do, and I used a silly hack to make it work—I built my objects as foo.oo instead of foo.o.

The problem is that ExtUtils::MM_Unix's c_o function returns a number of rules to create object files by compiling .c, .cc, and other files, but they all place the resulting object in the top-level directory. I didn't want to redefine everything in c_o, so I tried to override the .cc build rule in MY::postamble. That worked, but caused make(1) to complain about the duplicated rule.

So I picked an unused extension and created a build rule for it:

sub MY::postamble {'
%.oo: %.cc
	$(CXX) $(OPTIMIZE) $(DEFINE) $(INC) -o "$@" -c "$<"
'}

That worked perfectly. In my call to WriteMakefile(), I passed the names of the various "subdir/src/foo.oo" files in the OBJECT list. The objects were built by the rule, and EU::MM took care of linking them in. But I still wince a little when I see all the .oo files.

A simpler solution, adopted by Florian Ragwitz in Class::MOP, is to add "-o $@" to the build command in MY::const_cccmd().

Life with cpanminus is different

cpanm makes it so much easier to deal with CPAN module dependencies.

Read more…

Net::XMPP virtual hosting support

A patch to enable Net::XMPP to connect to Jabber virtual hosts.

Read more…

HTTP::Parser 0.04 bugfix

An HTTP protocol version parsing bugfix for HTTP::Parser 0.04

Read more…