GoDaddy's double 302 (was Dropping $_session elements)

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
jimburns
Forum Newbie
Posts: 8
Joined: Sun Jun 07, 2009 11:30 am

GoDaddy's double 302 (was Dropping $_session elements)

Post by jimburns »

This was originally a question regarding a loss of expected elements in the $_SESSION global on a login form that gets processed and redirects back to the starting index page and uses that $_SESSION global to indicate success for failure on login, and thus how to react, login form again, or starting page. I appreciate the thoughts from Jackpf and from the start I have been tracking the contents of $_SESSION via a trace log of the process. As I said in my first note, at the very end of the form script, the $_SESSION global has everything I expect it to have, then it redirects back to the index page, and immediately, my logs show $_SESSION is empty of my control values. It's not quite that simple as below explains.

I've started a new thread because the original subject no longer accurately describes where my search has lead me.

I started thinking this all had a lot to do with session management but I've been able to rule that out. The session management appears to be working, consistent session id's are passed and recovered on both sides of the redirect.

But I did find something unusual, or at least to my experience in how GoDaddy is handling the form processing. In fact I've read quite abit about GoDaddy's unusual, sometimes random 302 redirects and double 302 redirects in conversations involving using paypal on some sites. How this relates to simple form processing I'm not sure, but it does give a hint in the right direction.

Using an http packet sniffer I find that on the hostmonster site, the initial request is a POST and the 302 response looks pretty much as one would expect. The response packet is 302 and the location is the index.php, the redirect back to the main page.

But on the GoDaddy site, the 302 is a POST and looks almost perfectly the same, but the 302 response gives a location back to the form processing script, so back to itself, another request is made, this time however it's a GET request, session ID matches the first request so the session management appears to be working, and this time the response is another 302 but this time the location is back to the main index.php. Make no mistake, I never redirect back to the form script in any of my code. But this redirect is happening and, again, this time the submission turns from a POST to a GET. Why in the world would the server respond on my initial request to the form script with a 302 back to the form script? I'm not doing that, and it doesn't happen on my hostmonster site.

So why the double 302 and what is the genesis of a POST first (my html form does use method="POST") with a redirect back to the form script and another attempt with a GET? I'm not sure how the transformation from POST to GET happpens, this decision is made at the browser no? Is it standard that if a server responds with a 302 but the location is the same that the browser change its submission method?

KEEP in mind, my source files are identical for both systems, hostmonster and GoDaddy. I've reposted some of this from my old thread as I wanted the subject to reflect my current findings, I appreciate the board's patience.

Thoughts? I'm posting the http conversation below, keep in mind this is all one conversation that takes place with a single mouse click on the submit button of the login form, there's nothing you're not seeing in between these request and response packets.

TIA,

/jim

Code: Select all

POST /myadmin/c_form_process.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://www.myurl/myadmin/index.php
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: myurl
Content-Length: 33
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: PHPSESSID=qbd6fj7c61poekhur30outss80
 
HTTP/1.1 302 Moved Temporarily
Date: Mon, 03 Aug 2009 23:52:52 GMT
Server: Apache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Location: /myadmin/c_form_process.php
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
 
GET /myadmin/c_form_process.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://www.myurl/myadmin/index.php
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: myurl
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: PHPSESSID=qbd6fj7c61poekhur30outss80
 
HTTP/1.1 302 Moved Temporarily
Date: Mon, 03 Aug 2009 23:52:53 GMT
Server: Apache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Location: http://www.myurl/myadmin/index.php
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
 
Post Reply