So, while I'm not 100% sure about this, logically the $r->content_type should be empty before the response is prepared to be sent to the browser, so it should be empty in the Fixup stage.
not necessarily.
if you request index.html, mod_mime (at the mime-type phase) will set the content type to text/html based on the file extension. mod_mime_magic will do the same, but by analyzing the contents of the file.
if you are generating dynamic content and there is no file type to examine (or consistently relate, as .cgi can produce multiple CTs), no default type, and no file to examine, then there is no way the mime modules can set a content type. the end result would be undef in fixup and beyond.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that would take the $r from the "newly born" state and describe what's added/deleted to it during a full process loop, at each stage.
there is lots of documentation on this kind of thing, but nothing specific like "$r->content_type is set during the mime-type phase" because things like this are dependent on varying circumstances.
Part III of the mod_perl Developer's Cookbook talks about the each phase of the request cycle in depth. you can read part of it from http://www.modperlcookbook.org/. the eagle book also covers it.
Besides I'd like to know about each major optional module (like mod_rewrite, mod_ssl, etc) where they intervine in the loop and what they read/or set. Most of these one can guess but I'm not aware of such a documentation.
that's complex. for instance, mod_rewrite can enter just about every part of the request cycle, depending on how it's configured.
the way to discover this is to look at the code (remember, it's open :) - at the end of each extension module is the place where hooks are typically registered. look for a line such as
module MODULE_VAR_EXPORT rewrite_module = {
which begins the list of phases the module hooks into.
HTH
--Geoff
