Thanks all for your help. But there is alot going on here. Let me
summarize...
1. When the .php->.php.html redirect was introduced a few days ago, my
testing with FF (a GET) didn't work as something goofed-up the PHP
$_REQUEST array. So two chaps on this list kindly suggested I introduce
something like this to my code:
// get the request query bits
if (strpos($_SERVER["REQUEST_URI"], "?")) {
$QueryString = explode("?", $_SERVER["REQUEST_URI"]);
$QueryArray = explode("&", $QueryString[1]);
foreach ($QueryArray as $QueryItem) {
$QuerySegment = explode("=", $QueryItem, 2);
$_GET[$QuerySegment[0]] = urldecode($QuerySegment[1]);
}
}
I would then get my input parameters via the $_GET array rather than the
$_REQUEST array. When I implemented this, my testing through the
redirect with FF worked. I could also point FF at the .php/html file
directly and get the expected result.
2. My addon is coded to use a POST rather than a GET (not sure why I did
this) via XmlHttpRequest. Of course, I finally figured out that when a
POST comes in, the code introduced above doesn't do anything meaningful
and so getting my parameters from the $_GET didn't work. After realizing
this, I have placed the above code and the getting of my parameter data
inside a conditional:
if(strcmp($_SERVER['REQUEST_METHOD'], "GET") == 0)
{
// get the request query bits
if (strpos($_SERVER["REQUEST_URI"], "?")) {
$QueryString = explode("?", $_SERVER["REQUEST_URI"]);
$QueryArray = explode("&", $QueryString[1]);
foreach ($QueryArray as $QueryItem) {
$QuerySegment = explode("=", $QueryItem, 2);
$_GET[$QuerySegment[0]] = urldecode($QuerySegment[1]);
}
}
// get input parameters
$DEBUG_ENABLED = $_GET["test"];
$EMAIL_ADDRESS = $_GET["emailAddress"];
$THUNDERPLUNGER_ID = $_GET["accessKey"];
}
else
{
$DEBUG_ENABLED = $_REQUEST["test"];
$EMAIL_ADDRESS = $_REQUEST["emailAddress"];
$THUNDERPLUNGER_ID = $_REQUEST["accessKey"];
}
So now, if the invocation is via GET or POST, the parameters should be
populated.
3. If I test the above with a GET via FF of either the .php (redirected)
or the .php.html (directly) I get the expected results. But the addon is
the only way I have right now to test POST'ing rather than GET'ing. I
fully expected that my addon's POST to the .php.html (directly) would
work just fine. And it does. However, if I have the addon POST to the
.php (as it has all along until the recent past), the code does not
perform as expected. It seems that the POST'ed data does not make it
through the redirection. I cannot be sure why.
4. So it seems that I have two choices: (a) change my code to GET rather
than POST or (b) users can change the addon's options so the addon will
post to the .php.html (directly) instead of the .php (redirect). The
former requires an addon update for all users while the latter requires
that all users somehow figure out that something is wrong and either
email me or go to the addon's website where I have posted information
about all this. I like the former because it requires no active
participation from my users save installing the updated addon (which
they should find out about automatically). But the addon update will
have to sit for who knows how long before it gets approved.
Thanks for everyone's help. This is just a less than great situation for
all, I guess.
David
Jesper Staun Hansen wrote:
well, yes
http://thunderplunger.mozdev.org/validateEmail.php
POST /validateEmail.php HTTP/1.1
Host: thunderplunger.mozdev.org <http://thunderplunger.mozdev.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; da; rv:1.9.2.10)
Gecko/20100914 Firefox/3.6.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: da,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: close
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 45
X-Forwarded-For: 12.13.14.15
Pragma: no-cache
Cache-Control: no-cache
test=1&emailaddress=whiteldavl...@fastmail.us
<mailto:whiteldavl...@fastmail.us>
HTTP/1.1 302 Found
Server: nginx/0.7.62
Date: Fri, 01 Oct 2010 20:07:20 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: close
Location: http://thunderplunger.mozdev.org/validateEmail.php.html
Content-Length: 314
----------------------------------------------------------
http://thunderplunger.mozdev.org/validateEmail.php.html
GET /validateEmail.php.html HTTP/1.1
Host: thunderplunger.mozdev.org <http://thunderplunger.mozdev.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; da; rv:1.9.2.10)
Gecko/20100914 Firefox/3.6.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: da,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
X-Forwarded-For: 12.13.14.15
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 500 Missing or incorrect access key
Server: nginx/0.7.62
Date: Fri, 01 Oct 2010 20:07:20 GMT
Content-Type: text/html
Connection: keep-alive
X-Powered-By: PHP/5.2.12
Status: 500 Missing or incorrect access key
Content-Length: 111
On Fri, Oct 1, 2010 at 10:06 PM, Pete Collins <p...@mozdevgroup.com
<mailto:p...@mozdevgroup.com>> wrote:
Ah, never mind.
I see the error in the status text.
Good, I have a test case to fix this now.
--pete
--
Pete Collins - Founder, Mozdev Group Inc.
www.mozdevgroup.com <http://www.mozdevgroup.com>
Mozilla Software Development Solutions
tel: 1-719-302-5811
fax: 1-719-302-5813
_______________________________________________
Project_owners mailing list
Project_owners@mozdev.org <mailto:Project_owners@mozdev.org>
https://www.mozdev.org/mailman/listinfo/project_owners
------------------------------------------------------------------------
_______________________________________________
Project_owners mailing list
Project_owners@mozdev.org
https://www.mozdev.org/mailman/listinfo/project_owners
_______________________________________________
Project_owners mailing list
Project_owners@mozdev.org
https://www.mozdev.org/mailman/listinfo/project_owners
