You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "Scott A. Wozny" <sa...@hotmail.com> on 2021/02/13 00:04:10 UTC

[users@httpd] Re: Value of DOCUMENT_URI inconsistent in nested SSI, if vs echo

OK, so why DOCUMENT_URI means one thing in an echo and something else is an 'if' test when inside a nested SSI is still a mystery, but I thought I'd post my workaround in case someone finds this in the future.  Basically, all I did was set a variable inside nested.shtml and then referred to THAT instead of the server variable for my tests.

Also, I needed to use the 'v' shortcut function for my tests since trying to do an 'if' against the variable I set directly caused Apache to tell me (I think erroneously) that the expression couldn't be parsed because the variable didn't exist RIGHT AFTER I set and echo'ed it.  Anyway, here's the new code for nested.shtml that works, now.

<br>Now that we're in nested.shtml, per an SSI echo, the name of this document is:
<!--#echo var="DOCUMENT_NAME"-->
<br>
<!--#set var="pageName" value="$DOCUMENT_NAME" -->
Now I've put the value of DOCUMENT_NAME into a variable called pageName.  It's value is:
<!--#echo var="pageName" -->
<br>
And now I'm going to assess it inside an 'if' test.
<br>
<!--#if expr='v("pageName") == "indirect.shtml"' -->
Per an SSI 'if' test, this variable is set to indirect.shtml
<!--#else -->
Per an SSI 'if' test, this variable is NOT set to indirect.shtml
<!--#endif -->
<br>
<!--#if expr='v("pageName") == "nested.shtml"' -->
Per a second SSI 'if' test, this variable is set to nested.shtml<br>
<!--#else -->
Per a second SSI 'if' test, this variable is NOT set to nested.shtml<br>
<!--#endif -->

And the results are what I expected:


Per an SSI echo in the main file, the name of this document is: indirect.shtml
Now we're going to include nested.shtml.

________________________________

Now that we're in nested.shtml, per an SSI echo, the name of this document is: indirect.shtml
Now I've put the value of DOCUMENT_NAME into a variable called pageName. It's value is: indirect.shtml
And now I'm going to assess it inside an 'if' test.
Per an SSI 'if' test, this variable is set to indirect.shtml
Per a second SSI 'if' test, this variable is NOT set to nested.shtml

Scott

________________________________
From: Scott A. Wozny <sa...@hotmail.com>
Sent: February 9, 2021 8:29 PM
To: users@httpd.apache.org <us...@httpd.apache.org>
Subject: [users@httpd] Value of DOCUMENT_URI inconsistent in nested SSI, if vs echo


Greetings Apache gurus!


My attempted use case is to use Apache server side includes to adjust the styling of a NavBar, highlighting the active page, but it’s not working. The reason why is that in a nested SHTML file, it appears the the variable DOCUMENT_URI, when referenced by an <!--#echo is the document requested by the user (which, I think, is how it should be) but when referenced by an <!--#if expression, it is the nested document (which, I think, is incorrect) but I have no idea why.


Rather than dump all the code here for my home page and nav bar, I wrote a quick proof of concept that seems to demonstrate my issue focusing directly on the SSI.


Here is my baseline to make sure my basic code and expressions are correct.


File: direct.shtml

<!DOCTYPE HTML>

<html lang="en">

<head>

<meta charset="UTF-8">

</head>

<body>

<p>

Per an SSI echo, The name of this document is: <!--#echo var="DOCUMENT_NAME"-->

<br>

<!--#if expr="%{DOCUMENT_URI} == '/direct.shtml'" -->

Per an SSI if test, this file is called /direct.shtml

<!--#else -->

Per an SSI if test, this file is NOT called /direct.shtml

<!--#endif -->

</p>

</body>

</html>


Produces this output:

Per an SSI echo, The name of this document is: direct.shtml
Per an SSI if test, this file is called /direct.shtml


Which is exactly as I expect.


Now, here is file: indirect.shtml

<!DOCTYPE HTML>

<html lang="en">

<head>

<meta charset="UTF-8">

</head>

<body>

<p>

Per an SSI echo in the main file, the name of this document is:

<!--#echo var="DOCUMENT_NAME"-->

<br>

Now we're going to include nested.shtml.

<hr>

<!--#include virtual="nested.shtml" -->

</p>

</body>

</html>


And the referenced file: nested.shtml

<br>Now that we're in nested.shtml, per an SSI echo, the name of this document is:

<!--#echo var="DOCUMENT_NAME"-->

<br>

<!--#if expr="%{DOCUMENT_URI} == '/indirect.shtml'" -->

Per an SSI if, this file is called /indirect.shtml<br>

<!--#else -->

Per an SSI if, this file is NOT called /indirect.shtml<br>

<!--#endif -->

<!--#if expr="%{DOCUMENT_URI} == '/nested.shtml'" -->

Per a second SSI if, this file is called /nested.shtml<br>

<!--#else -->

Per a second SSI if, this file is NOT called /nested.shtml<br>

<!--#endif -->


Which produces this output:

Per an SSI echo in the main file, the name of this document is: indirect.shtml

Now we're going to include nested.shtml.

--------------------

Now that we're in nested.shtml, per an SSI echo, the name of this document is: indirect.shtml

Per an SSI if, this file is NOT called /indirect.shtml

Per a second SSI if, this file is called /nested.shtml


So having DOCUMENT_URI meaning one thing in an echo and something else in an if, but ONLY when in a nested SSI doc is the mystery I’m trying to solve. Have I done something wrong, are my assumptions incorrect, or is my Apache instance misbehaving?


Even if you don’t have an answer to WHY, would someone with Includes turned on in their environment be willing to try my code to see if you get the same output, just to see if this issue is unique to my environment? I’m using the 2.4.6-93.el7.centos build, at present, for testing.  I know it's WAY out of date, but I'm trying to stick with the managed package for my distro.  Either way, this doesn't seem like a terribly weird use case or an exotic function.


Any suggestions would be appreciated. I think I can fix this on the client side in JavaScript, but I’d like to know if I’ve done something wrong in my code as I rely on SSI in other places and if I can’t rely on it the way I’m using it I’d like to know.


Thanks,


Scott