www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: config/495: AddType application/x-javascript .js breaks SSIs in IncludesNOEXEC dirs
Date Mon, 28 Apr 1997 18:50:02 GMT
The following reply was made to PR config/495; it has been noted by GNATS.

From: Dean Gaudet <dgaudet@arctic.org>
To: Steven Champeon <schampeo@hesketh.com>
Subject: Re: config/495: AddType application/x-javascript .js breaks SSIs in IncludesNOEXEC
Date: Mon, 28 Apr 1997 11:41:35 -0700 (PDT)

 The current behaviour sounds correct to me.  Don't name your SSIs with a
 .js... if you want them to be called something other than .html you could
 try .htmlf (html fragment) and "AddType text/html htmlf".  We open up lots
 of potential problems by changing this.
 On Mon, 28 Apr 1997, Steven Champeon wrote:
 > >Number:         495
 > >Category:       config
 > >Synopsis:       AddType application/x-javascript .js breaks SSIs in IncludesNOEXEC
 > >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:     schampeo@hesketh.com
 > >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:

View raw message