httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Hewitt" <ada...@staff.iinet.net.au>
Subject RE: [users@httpd] Apache2 + userdir + suexec -- getting there :S
Date Thu, 08 Dec 2005 04:00:30 GMT
Sorry to reply to my own post, but I have fixed it... adding a [PT] to
the end of the rewrite rule fixed the problem.
 
thanks,
 
Adam.


  _____  

	From: Adam Hewitt 
	Sent: Thursday, 8 December 2005 11:47 AM
	To: users@httpd.apache.org
	Subject: [users@httpd] Apache2 + userdir + suexec -- getting
there :S
	
	
	Hi All,
	 
	I am now one step further in diagnosing/fixing this issue that I
am currently experiencing.
	 
	I now have a test setup which has removed all LDAP functionality
and is reading directly from the /etc/passwd file. Now, if someone
browses to
http://members.domainname.com.au/~username/cgi-bin/filedel.cgi I have a
rewrite in place to change the ~username to ~username@domainname.com.au,
which matches the user I have in the /etc/passwd file. This works for
normal html pages, but it still fails for cgi's.
	 
	I have ruled out suexec as being the issue altogether. I
modified the suexec code to output the arguments it was recieving from
apache right at the beginning of the code, and found that if I remove
the rewrite and use the full username in the URL then it works and
suexec outputs to the log, but if I use the rewrite it fails and I get
no output to the log file. Therefore the issue is laying somewhere
inside the apache code.
	 
	So, can anyone suggest a way to keep the browser from seeing any
rewrite so that there is no change from ~username from the customers
point of view, or sugegst any reason why this would be failing? I feel
that this is an apache bug, but it may be by design...and my C skills
are not high enough to be able to go through the entire apache code base
to try and modify my version to get around this issue.
	 
	Cheers,
	 
	Adam.


Mime
View raw message