| Summary: | SSI "exec cmd=" vis- | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Joel Parramore <parramorej> |
| Component: | mod_include | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED INVALID | ||
| Severity: | major | ||
| Priority: | P1 | ||
| Version: | 2.0.53 | ||
| Target Milestone: | --- | ||
| Hardware: | Sun | ||
| OS: | Solaris | ||
I would guess that mod_jk is changing the CWD, and thats why the cmd= fails, while virtual= works correctly. Marking invalid as an HTTPD bug, its something that mod_jk is doing to the enviroment. Also, using virtual might be the prefered method for other reasons.. I will go ahead and open up this issue on the tomcat/mod_jk side of things and see how matters progress --- thanks. Outside of the issue of not being able to run the header/footer script as a CGI program, why would '#include virtual be preferred? I had found at one time that some environment variables aren't passed along to scripts invoked using that as opposed to #exec cgi, so would be reluctant to do that. |
I’m working on porting some legacy code into Java, piecewise. The legacy code has a script (which I have to keep for now) that generates a header and footer separately for a page using SSIs for a given HTML page request, e.g., a page on the server would look like <!--#exec cmd=”/path/to/headerfooterscript --showheader”--> … (some HTML or other SSI directives here) … <!--#exec cmd=”/path/to/headerfooterscript --showfooter”--> Instead of HTML files now, I have JSPs. I have an Apache (2.0.53) installation handing off requests to a Tomcat (5.5.7) server via mod_jk (1.2.8). The output from those requests has the header/footer includes in it, after which Apache is configured to process the output for the SSIs (using “SetOutputFilter INCLUDES” in the configuration) and run those. Apache parses the output for SSIs but fails to run the “headerfooterscript”, returning this message in the log: (2)No such file or directory: change of working directory failed The directory exists, the script exists, it’s executable, the Apache user has permissions to run it, but I get this message. Doing a little debugging, I see that the value that Apache has for the working directory is empty. Now, one odd thing is that doing this works if I use “#exec cgi” or “#include virtual” commands in the JSP output instead of “#exec cgi” (using either of those is undesirable for other reasons right now), it works --- I get the output from a test script or file included in the output from the JSP. The other odd thing is that if I write a plain CGI script (Perl in this case) to return as output the header/footer includes using the “#exec cmd” syntax, it also works --- no “(2)No such file or directory: change of working directory failed” messages. Debugging shows that the value for the working directory is being set correctly for all the working cases. So it appears that it might be a bug vis-à-vis Apache and mod_jk (but I'm filing it under mod_include for the moment) in some fashion, either before the request is handed off, or after it comes back. I should note that the original issue was spotted under Solaris 8, but it also happens under Solaris 9. Also, I don’t have any third-party modules compiled either. I haven’t tested Apache under Linux (wouldn’t be the production environment anyway) to see if it also happens there.