Well, thank you very much for the references. I guess I'll have to skip next few pints and finally get that book I've heard so much about ;-)
Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net > -----Original Message----- > From: Geoffrey Young [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 07, 2003 3:15 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: help on setting up a PerlFixupHandler > > > > > > > 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 > >
