kevin furze wrote:
it is the " Serve Files " setting that controls the problem.
set this option to YES, activate the changes and hey presto, the files " .INC " now works set it to NO and ONLY the " .CSP " files work.
It sounds like ISC introduced a security problem then. If serve files is on, %CSP.StreamServer will serve *any* file in your CSP tree - including the source of CSP pages, rules, and whatever else you may have there. This may help people with an unhealthy interest in your application. If you don't want to open up that possibility, you are *still* forced to change your source.
Personally, I think this change (restricting the supported file extensions for csp:include) is a bad thing, especially when making it dependant on the serve files setting (although that may have been there before somehow, I don't know). AFAICS, the *only* difference between csp:include and <--#include --> is (or should be) that the former does a runtime inclusion, and the latter a compile-time one. As a runtime substitution usually makes more sense (no need to recompile all pages if you change the include), people are more likely to use that one.
This is not exactly the case in my opinion. As I stated earlier the one is a runtime inclusion and therefore logically must/should be another CSP page. The Serve Files option is dangerous and should be off as a general rule. I agree with Kevin that changing the behavior or tightening it so late in the game is not playing nice and should be documented but this flag is even worse in my mind.
I see no reason for stating, as the docs do, that using one includes a CSP "page" and the other a text file. Include files contain fragments (of code, HTML, or whatever else), calling that a CSP page is misleading, IMHO.
(As to the subject of parameters: both include versions support COS expression substitution in the usual form: #(COS)#. You may be able to use that to your advantage -- unless ISC decides to change that, too...)
Gertjan.
