Does any of this need to be covered in an ARC case? 1. A reference guide is now included:
Presumably the reference guide will now be installed with the OpenSolaris package SUNWapch22m-fcgid. /usr/apache2/2.2/manual/mod/mod_fcgid.html /usr/apache2/2.2/manual/mod/mod_fcgid.html.en (view at http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html) 2. Some directives which were allowed inside <VirtualHost ...> but previously ignored there are processed differently now: a. Some are now respected inside <VirtualHost ...>. b. The remainder are now rejected at startup when appearing inside <VirtualHost ...>. 3. I think this is making a mountain out of a molehill, but for completeness: Bug fixes in the handling of inherited mod_fcgid configuration (e.g., <VirtualHost ...> inheriting from the global server, or <Directory /a/b/c> inheriting settings from <Directory /a/b>) mean that existing configurations can work slightly differently in rare circumstances. Generally, the old behavior meant you had to overspecify in the sub-container, which would still work with 2.3.4. Without overspecifying in the subcontainer, as soon as you put one mod_fcgid directive in the subcontainer you'd get defaults for the other settings instead of inheriting from the parent container. If that was actually the desired configuration, it will now be broken. Example: <Directory /a/b> Setting1 value1 Setting2 value2 </Directory> When a request is for file in directory /a/b/c, value1 and value2 were used for that request, in both versions of mod_fcgid. If you then added this: <Directory /a/b/c> Setting3 value3 </Directory> mod_fcgid 2.2: Setting1 and Setting2 now have their default values for files in directory /a/b/c. mod_fcgid 2.3.4: Setting1 and Setting2 values are inherited from <Directory /a/b>, Setting3 has value3. (The old behavior was not how any bundled Apache modules work.) 4. While existing directive names are still respected, every directive has a new, preferred name. The reference guide has a mapping table.
