ap_add_common_vars() clobbers existing values?

[Adrian Hosey <ah...@systhug.com>]

I was originally trying to use SetEnv to override the usual value of the
SERVER_NAME (and HTTP_HOST) variables. We have multiple backend servers
muxed by a frontend proxy, so I want CGIs running on the backend machines
to all see the same hostname in their environment, right?

I found that even though SetEnv was setting SERVER_NAME to what I wanted,
the call to ap_add_common_vars() in mod_cgi.c was clobbering the existing
value with its new value (where the new value is the one I'm trying to
override!) This is because of the use of ap_overlap_tables() right? This
seems counterintuitive to me. Was there a deliberate decision to give the
newer values precedence or did it just happen to be coded that way? Can I
make the case that existing values should get precedence?

Thanks,

	- A

-- 
http://web.systhug.com/
Beware of bugs in the above code; I have only proved it correct, not tried
it. - Donald Knuth

Re: ap_add_common_vars() clobbers existing values?

[Galvanick Lucipher <ah...@systhug.com>]

On Sun, 5 Nov 2000, Tony Finch wrote:
: Adrian Hosey <ah...@systhug.com> wrote:
: >
: >Those are good questions. It's a complicated setup - for a while we were
: >using ServerName to the desired effect, but now we need each backend
: >server to have a distinct ServerName in order to do some things with
: >mod_auth_radius.
: 
: That sounds rather sordid.

Heh. I guess that's one way to put it... by using a PAMified radius server
we can apply PAM stacks to web authentications, which I think is way
cool. We give different service packages to different groups of users by
routing them to one backend server or another, which is why we need the
servers to be distinct to the radius server.

: Your patch won't cause breakage. I expect there isn't much reason for
: the order of priority except to ensure that the CGI environment
: variables are what they should be, with the assumption that there's no
: reason to need to ovveride them because the server gets it right.

Okay, that's good to know. If the behavior is arbitrary what are the
chances of getting it changed in the ap_* routines? It seems that if an
admin sets a var with SetEnv the Principle of Least Surprise would say
that setting should stick everywhere, even if it's one of vars normally
manipulated by ap_add_common_vars() or others. The current behavior
appears that some variables magically change at the last minute while
others don't, with no explanation unless you understand what's happening
in the code. If I make a patch will someone put it in?

Thanks,

	- A

-- 
http://web.systhug.com/
This is going to get worse before it gets better.

Re: ap_add_common_vars() clobbers existing values?

[Tony Finch <do...@dotat.at>]

Adrian Hosey <ah...@systhug.com> wrote:
>
>Those are good questions. It's a complicated setup - for a while we were
>using ServerName to the desired effect, but now we need each backend
>server to have a distinct ServerName in order to do some things with
>mod_auth_radius.

That sounds rather sordid.

>I have a hack to mod_cgi which copies the existing subprocess_env table
>and then overlaps the copy _again_ before exec'ing the CGI, effectively
>"unclobbering" the clobbered vars. But I'm not happy with this hack
>because (1) it's gross (b) I have to wonder if there's a _reason_ the
>designer of these ap_* functions gave precedence to the new vars, in which
>case my patch could potentially cause breakage.

Your patch won't cause breakage. I expect there isn't much reason for
the order of priority except to ensure that the CGI environment
variables are what they should be, with the assumption that there's no
reason to need to ovveride them because the server gets it right.

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net

Win32 File/Directory changes info

[jlwpc1 <jl...@mail.earthlink.net>]

Seems like Apache was looking for some info on file/directory changes?

The ReadDirectoryChangesW function retrieves information describing the changes occurring within a directory.

http://msdn.microsoft.com/library/psdk/winbase/filesio_97av.htm


The FindFirstChangeNotification function creates a change notification handle and sets up initial change notification filter conditions. A wait on a notification handle succeeds when a change matching the filter conditions occurs in the specified directory or subtree. 

http://msdn.microsoft.com/library/psdk/winbase/filesio_9hgu.htm


Why not use the Win32 OS Shell functions?

SHGetFileInfo

IShellFolder::GetAttributesOf

SHChangeNotify

Notifies the system of an event that an application has performed. An application should use this function if it performs an action that may affect the shell. 

http://msdn.microsoft.com/library/psdk/shellcc/shell/Functions/SHChangeNotify.htm

An application notifies the shell by calling SHChangeNotify with the details of what has changed. The shell can then update its image of the namespace to accurately reflect its new state.

Simple Example of Managing Files with SHFileOperation

http://msdn.microsoft.com/library/psdk/shellcc/shell/Shell_basics/Manage.htm

Managing the File System
The shell provides a number of ways to manage file systems. The shell provides a function, SHFileOperation, that allows an application to programmatically move, copy, rename, and delete files. The shell also supports some additional file management capabilities:

Snip

Notifying the Shell
Notify the shell of the change after using SHFileOperation to move, copy, rename, or delete files, or after taking any other action that affects the namespace. Actions that should be accompanied by notification include:

 Adding or deleting files or folders. 
 Moving, copying, or renaming files or folders. 
 Changing a file association. 
 Changing file attributes. 
 Adding or removing drives or storage media. 
 Creating or disabling a shared folder. 
 Changing the system image list. 

All the above are part of the Win32 OS!

JLW

Re: ap_add_common_vars() clobbers existing values?

[Adrian Hosey <ah...@systhug.com>]

On Fri, 3 Nov 2000, Tony Finch wrote:
: Adrian Hosey <ah...@systhug.com> wrote:
: >
: >I was originally trying to use SetEnv to override the usual value of the
: >SERVER_NAME (and HTTP_HOST) variables. We have multiple backend servers
: >muxed by a frontend proxy, so I want CGIs running on the backend machines
: >to all see the same hostname in their environment, right?
: 
: Why doesn't UseCanonicalName do the right thing? Or alternatively why
: not set ServerName to the right value in the first place? It doesn't
: have to be the same as the machine's hostname or dns name.

Those are good questions. It's a complicated setup - for a while we were
using ServerName to the desired effect, but now we need each backend
server to have a distinct ServerName in order to do some things with
mod_auth_radius. So I added ProxyPassReverse to prevent URL munging but
that doesn't help the ENV variables for CGIs running on the backend
machines. Any manipulation of those particular ENV variables (SERVER_NAME
and HTTP_HOST) done with SetEnv or mod_rewrite gets clobbered by the cgi
handler's call to ap_add_common_vars().

I have a hack to mod_cgi which copies the existing subprocess_env table
and then overlaps the copy _again_ before exec'ing the CGI, effectively
"unclobbering" the clobbered vars. But I'm not happy with this hack
because (1) it's gross (b) I have to wonder if there's a _reason_ the
designer of these ap_* functions gave precedence to the new vars, in which
case my patch could potentially cause breakage.

Comments?

(Thanks for taking the time to discuss this.)

-- 
http://web.systhug.com/
"Aw, Mom... You know I'm not like other guys. I'm nervous and my socks are
 too loose."

Re: ap_add_common_vars() clobbers existing values?

[Tony Finch <do...@dotat.at>]

Adrian Hosey <ah...@systhug.com> wrote:
>
>I was originally trying to use SetEnv to override the usual value of the
>SERVER_NAME (and HTTP_HOST) variables. We have multiple backend servers
>muxed by a frontend proxy, so I want CGIs running on the backend machines
>to all see the same hostname in their environment, right?

Why doesn't UseCanonicalName do the right thing? Or alternatively why
not set ServerName to the right value in the first place? It doesn't
have to be the same as the machine's hostname or dns name.

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net