[Xitami] RE: POST troubles (longish)

[Boyan Brezinsky]

Thanks for the tips. I've found and worked around the problem, now the 
question is if it is a bug in Xitami or some misunderstanding by the 
developer of dcl.
On login, dcl sends user name, password and so on to login.php3.
login.php3 in turn calls its own function Refresh(). This function is used 
to redirect the server to a new file - main.php3 or listFrame.php3, 
depending on your choice of frames or not.
The Refresh() function can use two types of redirect - through the php 
Header() function or through html meta tags.
The relevant part is:
		if ($GLOBALS['cookieMethod'] == 'header')
		{
			$hdr = '';
			if ($GLOBALS['redirMethod'] == 'php')
				$hdr = "Location: $toHere\n";

			$hdr .= "Set-Cookie: DCLINFO=$theCookie\n";
			$hdr .= "Set-Cookie: DCLTYPEMENU=$DCLUI\n";
			$hdr .= "\r\n";

			Header($hdr);
			if (substr($toHere, 0, 10) == 'index.php3')
				exit;
		}
<snip some code>
		print('<html><head>');
<snip a little more>	
		print("<meta http-equiv=\"refresh\" content=\"00;URL=$toHere\">");
		print('</head>');
<and snip till end of function>

In the non-working configuration I have $redirMethod=="php" and 
$cookieMethod=="header"
In the working configuration the $redirMethod is set to "meta".
In both cases the $toHere variable gets the value 
"main.php3?menuAction=boMyDCL.show" (actually, the php3 filename depends on 
the type of the interface, but this is not important here). Unfortunately, 
it is hard-coded: Refresh('main.php3?menuAction=boMyDCL.show', $id, 
$thispwd, $GLOBALS['DCLUI'], $GLOBALS['LANG'], $GLOBALS['DOMAIN']);

In the non-working case the generated output is (from *.flt):
X-Powered-By: PHP/4.0.4
Location: main.php3?menuAction=boMyDCL.show
Set-Cookie: DCLINFO=1/0/dfe2c07de313f0d7ca27146e068767f1/en/default
Set-Cookie: DCLTYPEMENU=0
Content-type: text/html

<html><head><meta http-equiv="refresh" 
content="00;URL=main.php3?menuAction=boMyDCL.show"></head>



In the working case ($redirMethod=="meta") the generated output is:
X-Powered-By: PHP/4.0.4
Set-Cookie: DCLINFO=1/0/dfe2c07de313f0d7ca27146e068767f1/en/default
Set-Cookie: DCLTYPEMENU=0
Content-type: text/html

<html><head><meta http-equiv="refresh" 
content="00;URL=main.php3?menuAction=boMyDCL.show"></head>


As you can see, the difference is in the "Location:" header. The obvious 
reason is that Xitami can't find the file specified in the Location header 
and returns 404.
Now the question is if this is a bug or a feature. According to HTML 1.1 
definition from 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30:
"The field value consists of a single absolute URI.
       Location       = "Location" ":" absoluteURI  "
In this case the URI is definitely not an absolute one. So if this is the 
reason for the 404 error, I guess it's OK, although other users seem to be 
using this dcl software just fine. On the other hand, if for some reason 
Xitami tries, but cannot parse the "Location:" field, then it is a bug.

Thanks again,
Boyan


> From: Ewen McNeill <ewen@imatix.com>
> Subject: Re: [Xitami] POST troubles (longish)
> To: xitami@lists.xitami.org
> Date: Sun, 15 Jul 2001 21:08:57 +1200
> Reply-To: xitami@lists.xitami.org
>
> In message <01C10BA4.D1051D80.boyan@sanbolic.com>, Boyan Brezinsky 
writes:
>
> >Here is the story. Yesterday downloaded dcl - a project tracking system
> >written in PHP. At startup you have to login, supplying username and
> >password.  [Get 404 error when use Login]
>
> There's two things that could be generating the 404: Xitami and PHP.
> I can't remember off hand if Xitami logs a 404 only when it generates
> it, or when that's the code it's going to return (which a CGI/filter can
> supply).
>
> Since the request/debug log entries you supply don't match up with the
> times in the other snippets you supply, it's hard to know exactly what
> is going on.
>
> However I'd definitely suggest (a) looking for messages in cgierr.log,
> and (b) adding something to the PHP so you can tell if it is being run.
> The fact that Xitami seems to be trying to transfer .flt files (filter
> files), suggests that something must have generated those files to
> transfer.
>
> You might also want to enable [cgi] debug=1 (which controls filtering
> too) and let it preserve the filter files (normally they are removed
> after being sent).  Then you can check the contents of those to see if
> it is PHP that is writing the 404 error (or indeed if it is writing
> anything).
>
> Given that you seem to have a working PHP setup in general (since some
> of your other PHP works) I suspect that looking closely at what the
> problem PHP script is doing/trying to do has to be your next step.
>
> Ewen
>
> --
> Ewen McNeill, Technical Consultant, iMatix Corporation  www.imatix.com
>