Return-Path: 
 <users-return-48140-apmail-httpd-users-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-users-archive@www.apache.org
Received: (qmail 54417 invoked from network); 27 Dec 2004 19:12:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 27 Dec 2004 19:12:29 -0000
Received: (qmail 19555 invoked by uid 500); 27 Dec 2004 19:11:56 -0000
Delivered-To: apmail-httpd-users-archive@httpd.apache.org
Received: (qmail 19530 invoked by uid 500); 27 Dec 2004 19:11:56 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help: <mailto:users-help@httpd.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@httpd.apache.org>
list-post: <mailto:users@httpd.apache.org>
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 19512 invoked by uid 99); 27 Dec 2004 19:11:56 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net)
 (204.127.202.64)
  by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 27 Dec 2004 11:11:52 -0800
Received: from [172.30.44.35]
 (pcp07500698pcs.potshe01.pa.comcast.net[68.34.176.15])
          by comcast.net (sccrmhc13) with ESMTP
          id <20041227191147016003kvc3e>; Mon, 27 Dec 2004 19:11:48 +0000
Message-ID: <41D05E58.60800@nodivisions.com>
Date: Mon, 27 Dec 2004 14:11:20 -0500
From: Anthony DiSante <theant@nodivisions.com>
Reply-To: users@httpd.apache.org
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: users@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
Subject: [users@httpd] SSI redirection in standard header
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

I'm looking for a solution that doesn't involve any PHP, but which achieves 
this effect:


/head.php:
----------
<?PHP
if(!$session_cookie_exists && !$user_is_a_search_bot)
{
   header("Location: http://$HTTP_HOST/cgi-bin/set_session_cookie.cgi");
   exit;
}
else
{
   print_normal_site_header_stuff();
}
?>


/any_other_page.php:
--------------------
<?PHP include("$DOCUMENT_ROOT/head.php"); ?>

<!-- page content goes here -->


The result is that the user gets redirected -- transparently and temporarily 
-- to a script that sets a session cookie, and then he gets automatically 
returned to the page he originally requested.  So this is all invisible to 
the user.

But with SSI that doesn't work, because even if /head.shtml contains just 
this one line:

<!--#include virtual("/cgi-bin/set_session_cookie.cgi") -->

...that script can't do a Location:-redirect, because Apache has already 
started sending headers.  The best approximation I've been able to come up 
with so far is this:


/head.shtml:
------------
<!-- all normal site header stuff goes here -->


/any_other_page.shtml:
----------------------
<!--#if expr="$HTTP_COOKIE != /sess_id=foo/ && $HTTP_USER_AGENT = 
/Mozilla|etc/" -->

<meta http-equiv="refresh" 
content="0;url=http://me.com/cgi-bin/set_session_cookie.cgi">

<!--#else -->

<!--#include virtual="/head.shtml" -->

<!-- page content goes here -->

<!--#endif -->


That solution has a couple big problems, though:

1. it's a LOT of stuff to have to put at the top of every file on a website, 
especially compared to just include("$DOCUMENT_ROOT/head.php") in PHP.

2. the browser-list must be hard-coded, so whenever a new web-browser comes 
out, you'd have to edit every single file on the website, so you can add its 
name to the regex /Mozilla|etc/.

3. the HTTP_HOST (me.com) must be hard-coded too, so the same maintenance 
problems exist as in (2).

(Yes, the header in all any_other_pages.shtml can be updated by a simple 
shell/perl script, but even that is a nightmare to worry about when you're 
dealing with multiple servers, possibly ones on which you did the initial 
setup but are now not directly under your control.)

I don't want to use PHP because this is the ONLY thing I'd really need it 
for... and I'd rather not have to install PHP at all on my servers if I 
don't have to (since it's a pain to configure esp. compared to Perl, and 
since it's just one more thing to worry about upgrading/patching against 
exploits).  However, I don't see any good solution to this problem using 
just SSI/CGI.  If a CGI script could cause the server to stop sending its 
current output altogether and start outputting a different page (which is 
what the Location: header does, which can't be done through SSI), that would 
solve the problem, but other than that I'm not sure.  Any ideas?

Thanks,
Anthony DiSante
http://nodivisions.com/

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org