>Number: 495 >Category: config >Synopsis: AddType application/x-javascript .js breaks SSIs in >IncludesNOEXEC dirs >Confidential: no >Severity: serious >Priority: medium >Responsible: apache (Apache HTTP Project) >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Mon Apr 28 11:00:07 1997 >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.2b8 >Environment: # uname -a SunOS da 5.5 Generic_103093-08 sun4c sparc SUNW,Sun_4_75 # gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/specs gcc version 2.7.2 >Description: I use SSIs to include JavaScripts (which have the ending .js on our system). Another developer was using the AddType directive to add a MIME type for JavaScript, so he could do multipart-mixed responses, with the JavaScript in one section of the response, and the HTML in another (and thereby avoid sending back JavaScripts which could be seen via View Source). After he added the AddType, I started getting errors from my SSIs due to "unable to include potential exec" despite the fact that there is no Handler setup for .js files. Is this normal? If so, is it really correct?
I would think that a typed file without a handler or execute permissions could still be included from a directory even if IncludesNOEXEC was set. We're going to see more problems with this as more client-side scripting languages arrive. What do you guys think? >How-To-Repeat: Simple. srm.conf: AddType application/x-javascript .js test.html: (in dir with IncludesNoExec config set) <!--#include virtual="/path/to/javascript.js" --> >Fix: If a file of type X has no handler associated, is not executable, and is in a dir which allows Includes but NoExec, allow the file to be included. If this is not cool, maybe we need an IncludesNoExecButScriptsMayBeIncluded :%2 >Audit-Trail: >Unformatted:
