OK, I've been going nuts with this. I'm outputting a JSON from PHP, and the JSON View extension, for both Chrome and Firefox, is claiming it's invalid. Both extensions work correctly on JSON View's example, so it seems likely that there actually is something wrong with my JSON – but I have no idea what.
The Firefox version has an error message:
There was an error parsing the JSON document. The document may not be well-formed.
The Chrome version lacks such error messages, but still prints the JSON as plaintext.
I am setting the header, like so: header('Content-Type: application/json'); I've checked the response header in Firebug and Chrome's development tools; it is correctly set in both cases. Removing that hides the error message in the Firefox version and the plaintext is not in a monospace font, but that's it.
Complete request headers:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:msgPublishID=1347362550,1345649049; logout_rem=1; sh_rand=625703e7f9f9e03efabaef56f52ff97d7f68bc67; username=kryan; password=f85720746a490ece4dd7a945f5c9ed8e25b15f1f; fullname=Kevin+Ryan; user_type=1
Host:localhost
Pragma:no-cache
User-Agent:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1
Complete response headers:
Connection:Keep-Alive
Content-Length:371
Content-Type:application/json
Date:Thu, 27 Sep 2012 19:12:52 GMT
Keep-Alive:timeout=5, max=99
Server:Apache/2.4.2 (Win32) OpenSSL/1.0.1c PHP/5.4.4
X-Powered-By:PHP/5.4.4
I've gone through many variations on the JSON itself, but I can't imagine that it's the JSON's problem when something as simple as this:
{"session":"expired"}
is still failing. I've checked repeatedly; that is literally the entirety of the server's response, but JSON View still complains. For more complicated JSONs, I've been using
echo json_encode($output, JSON_PRETTY_PRINT);
where $output is an associative array; the output looks completely right but JSON View is still complaining. This is the only echo in the file that isn't commented out.
So what on earth could be going wrong here? I really need JSON View; I work with very large JSONs constantly and the ability to collapse and expand objects and arrays is critical to debugging my application. This online JSON viewer seems to work, but my productivity is going to take a hit if I have to copy and paste the output of these PHP files every time I'm testing them.
EDIT: One thing I have found that works is if I do this:
<?php
header('Content-Type: application/json');
die('{"debug":true}');
// remainder of the program as-is, starting with...
require('dbinfo.php');
If I then go with this:
<?php
header('Content-Type: application/json');
require('dbinfo.php'); // note this comes before the die statement
die('{"debug":true}');
// remainder of the program as-is
I get the error again.
So this implies that dbinfo.php is causing the problem.
EDIT: Sorry, I've removed dbinfo.php from this question because it might possibly contain sensitive data that should not be public (even though I stripped out the obvious things). Since the content of dbinfo.php wasn't relevant, it just seems safer to remove it. See my answer below.
Argh.
I figured it out: the BOM was screwing things up, but of course it was also being completely invisible. Checking and changing the encoding to UTF-8 without BOM fixed the problem entirely.
I don't know if this BOM thing is a problem with PHP's design or Unicode's design, but it is certainly obnoxious.
Related
I have been looking into an option to send data read from an attached file in an Outlook message, directly to a PHP script that will then insert the date in a nice MySQL database.
The extraction of the file and the splitting of data all ok, but here is the trick...
From the internet (here) I found a nice post by Jeremy Slade who has managed to send some data to a cgi scipt, all good.
So, clever as I thought I was, I thought I could re-write this into dealing with a PHP script.
But then the works stopped.
I have shortened the code to below snippet;
Sub TestURL()
Set xhr = CreateObject("MSXML2.XMLHTTP")
URL = "http://somedomain.com/php/test.php"
data = "someVariable=Test"
With xhr
.Open "POST", URL, False
.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
.Send data
End With
End Sub
This should, in theory, open a MSXML2.XMLHTTP request at the given URL and send whatever data with it to the script.
Funny enough, the script is called, but no data is passed ?
I've tried setting the PHP script to both $_GET and $_POST for the [someVariable] element, yet on neither is there any response ?
When I set the PHP to $_GET I matched the VBA MSXML2.XMLHTTP object to "GET" as well and vice versa...
I've tried passing the 'data' variable as argument to the 'function' .send by including it in brackets
i.e.
.send (data)
But this doesn't work either...
I'm a bit at a loss, because the script is called, a dataline is added to the table yet there is not an actual transfer of the 'sent' data ??
I've tried connecting the data string to the URL that is passed to the HTTP object, essentially passing a 'GET' URL to the HTTP object.
i.e.
URL = URL & "?" & data
but to no avail...:-(
The php script works in itself properly, if I pass data directly from the browser
i.e.
http://somedomain.com/php/test.php?someVariable=Test
the data is correctly added and the variable is read...
Can some more enlightened spirits guide me in the right direction ?
20141016 ********** UPDATE **********
Ok, when digging into stuff I found there is also an option to refer to the XmlHttp object as "Microsoft.XmlHttp" ?
Funny enough, when setting the object like that,
i.e.
Set xhr = CreateObject("Microsoft.XMLHTTP")
The code works and the data is added to the table and the .responsText is a success message.
Yet if I return to the original code, I get a PHP error message that tells me that there is an error in my PHP syntax ?? This would imply that the actual 'data' that is being send differs between using "MSXML2.XMLHTTP" and using "Microsoft.XMLHTTP" ???
Have tried to dig out the difference between the two from internet but can't find any post that provides me with a full understanding of the subject ?
Despite the fact that my code now works, I still have the bothering question of not understanding the difference between the two and would appreciate a reply from someone who does :-) As I now have a code that works, but not an understanding of why it works...:-)
Or mroeover not an understanding of why the "MSXML2" option does NOT work...
Much appreciated,
Kindest regards
Martijn
This is not exactly an answer but more like a comment as I lack enough reputation to comment.
The issue can be analyzed using Fiddler which provides details of the requests and responses. I checked the same code as yours in my system with both MSXML2.XMLHTTP and Mirosoft.XMLHTTP objects and found no difference in teh requests. Both of them passed the POST request body containing someVariable=Test to the URL http://somedomain.com/php/test.php.
Here is the raw POST request in both cases:
POST http://somedomain.com/php/test.php HTTP/1.1
Accept: */*
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; MS-RTC LM 8)
Host: somedomain.com
Content-Length: 17
Proxy-Connection: Keep-Alive
Pragma: no-cache
someVariable=Test
And the response from the sample URL provided:
HTTP/1.1 405 Method Not Allowed
Server: nginx/1.7.6
Date: Thu, 08 Jan 2015 15:23:58 GMT
Content-Type: text/html
via: HTTP/1.1 proxy226
Connection: close
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.7.6</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
One question here would be whether the web server in question is expecting further data to be passed by the way of headers (User-Agent, Referer, Cookies etc) or as part of the request body (may be further input elements that are part of the webform)?
locally and on the server, I get different results with the same code.
Locally my results arrive as string, while on the server, the same code returns JSON object. Can anybody tell me why?
The javascript:
$.post(
url, // Various urls of type '/users/add_secondary_email_ajax'
data,
function(res){
if (typeof(res.success)=='undefined'){
ModalManager.update_body_html(res);
}else{
callback_success(res);
}
}
);
The CakePHP:
$this->autoRender = false;
$this->RequestHandler->respondAs('json');
echo json_encode( array('success'=>true) ); // this arrives as string locally
return;
I also had this working on my other computer, but not this one. Could it be some PHP settings?
Both computers have the same versions of Browser & CakePHP version (2.2.3).
I see differences in PHP and Apache versions. Could be settings also, but I don't know where to look.
Header On Broken Computer:
Request URL:localhost/alert_subscribers/subscribe_ajax
Request Method:POST
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,bg;q=0.6
Connection:keep-alive
Content-Length:153
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie:timezoneoffset=-120; viewedJobsGuest=[24]; __atuvc=13%7C11%2C46%7C12; CAKEPHP=dfbf9407743d43eb619a42aa5dbda735; toolbarDisplay=hide
Host:jobsadvent.dev
Origin:URL:localhost
Referer:URL:localhost/search
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Data
data[title]:the title
data[email]:fake2#hotmail.com
data[alert]:1
Response Headers
Connection:Keep-Alive
Content-Length:57
Content-Type:text/html
Date:Fri, 21 Mar 2014 10:19:06 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.26 (Unix) DAV/2 PHP/5.4.24 mod_ssl/2.2.26 OpenSSL/0.9.8y
X-Powered-By:PHP/5.4.24
Header on Working computer
Request URL:http://domain.com/alert_subscribers/subscribe_ajax
Request Method:POST
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,bg;q=0.6
Connection:keep-alive
Content-Length:162
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie:__atuvc=1%7C10%2C5%7C11; timezoneoffset=-120; CAKEPHP=sb3013ffk40h7o1jhsl8ulqfj4; toolbarDisplay=hide
Host:domain.com
Origin:http://domain.com
Referer:http://domain.com/search
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Data
data[title]:the title
data[email]:fake#hotmail.com
data[alert]:1
Response Headers
Connection:close
Content-Length:57
Content-Type:application/json
Date:Fri, 21 Mar 2014 10:24:32 GMT
Server:Apache/2.2.15 (CentOS)
X-Powered-By:PHP/5.3.3
As for the routes.php file both are identical and contain the following line:
Router::parseExtensions('json');
This could be an issue with your apache settings:
The answer given on Apache sending incorrect response header for .js files suggests that you need something like
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
to get the right content types.
Refer to the jQuery.post() documentation. There is a fourth parameter (dataType) that you can use that will force jQuery to coerce the response to the correct datatype. You will need to set that equal to 'json' if you want an object back.
Well, no - computer 1 it is application/json and in the other it is text/html. Both have the same code I posted up there.
There's your problem. jQuery uses the response's Content-Type header as a guide.
The CakePHP docs seem to indicate that $this->RequestHandler->respondAs() may work better if you pass it application/json rather than just json.
JSON parsing should fix it.
$.post(
url, // Various urls of type '/users/add_secondary_email_ajax'
data,
function(res){
var result = JSON.parse(res);
if (typeof(result.success)=='undefined'){
ModalManager.update_body_html(res);
}else{
callback_success(res);
}
}
);
I would set the contentType and dataType in your $.POST request.
$.POST({
contentType : "application/x-www-form-urlencoded; charset=UTF-8",
dataType : "json"
})
when calling api:
$.post();
"dataType" param should be set as "json".if it is not sepecfied, ajax will intelligent guessed (xml, json, script, text, html...).see manual here:
so how could the ajax guess the type of data ?
There is a response header, "Content-Type:", by which the server tell the client what type is data. I think , ajax need this header to guess the data type.
this is your broken computer's response:
Content-Type:text/html
and this is your working computer's response:
Content-Type:application/json
if you don't want to specified the param "dataType" of $.post(), you can change the response header, there must be many ways to change it, like this:
<?php
header("Content-Type:application/json");
?>
That could be messy, but don't get worried until there's something to really worry about.
Statement of fact: one of your servers is behaving as expected and the other is not.
With the way that your error is manifesting, it sounds an awfully lot like you are not specifying your request specifically enough or your borked server is failing Content Negotiation.
There are two basic things that come into play here that you likely already know about: the requester's "Accept" header that allows the user agent to specify the content types that it is willing to receive and the server's ability to interpret that request and serve it appropriately. In absence of an explicitly set Accept header, text\html is the default response type.
Accept Header: RFC2616 Hypertext Transfer Protocol Section 14.1
The Accept request-header field can be used to specify certain media
types which are acceptable for the response. Accept headers can be
used to indicate that the request is specifically limited to a small
set of desired types, as in the case of a request for an in-line
image.
The asterisk "" character is used to group media types into ranges,
with "/" indicating all media types and "type/" indicating all
subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range.
The accept headers that you set for each request indicate that you don't care what the server gives you. You might try setting your accept header to application/json and see if the "broken" server can interpret it and serve you. If that works, then it seems you're just running into an inconsistency with the way the servers are defaulting their response types. This even looks to be what you're asking for it to do. You said you accept all response types. If you don't specify something specific, the most reasonable type for a server to give you is text/html
MIME Types: RFC 2046 Multipurpose Internet Mail Extensions
JSON: RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)
If setting the Accept header doesn't work for you, you're going to want to check your server's MIME type registration to make sure that [application\json] is registered and configured. That is not an esoteric configuration subject, so it should be available in any server's configuration documentation.
If neither of those approaches work, then the solution is to unplug the offending machine, carry it to the top of the building, and throw it as far as you can.
I'm using WordPress together with the JSON API Plugin (http://wordpress.org/extend/plugins/json-api/) to generate responses to our other site.
I've hit a really weird problem (we're using PHP 5.3.6), when I pass the following array http://pastebin.com/xdfYjrvK to json_encode() it gives me this (with json content-type): http://pastebin.com/T61XGPP5
So the crap in the beginning, in the above example it's 2609 and 0 in the end, it changes depending on the size of the response, more content -> higher hex number. It also appears only when the amount of response is "high enough", so it works on small responses.
First I thought it was the plugin, but it works locally (on two different machines Mac OS X) and we've updated all packages on the VPS (Debian, Apache, Nginx, PHP) to the latest versions.
It's only displayed when sending the content-type, not when outputting the $result with plain text instead of application/json:
$charset = get_option('blog_charset');
if (!headers_sent()) {
header('HTTP/1.1 200 OK', true);
header("Content-Type: application/json; charset=$charset", true);
}
echo $result;
$charset is set to utf-8.
The Google chrome console says: "Resource interpreted as Document but transferred with MIME type application/json."
So, does anyone have a clue whats happening here?
This looks like chunked encoding (http://en.wikipedia.org/wiki/Chunked_transfer_encoding). Make sure to check that your headers are setting the Content-Length properly in the response to make sure you aren't forcing the web server to use CTE.
One requirement json have is that all data you give to it must be UTF-8 encoded. json_encode() does not do this automaticly. So you can try to run this array_map("utf8_encode", $array); before you json_encode it.
Else... It looks weird, so Im just guessing...
I'm been stuck on this problem for a while and I'm pretty sure it must be something quite simple that hopefully someone out there can shed some light on.
So, I'm currently using jQuery UI's Autocomplete plugin to reference and external PHP which gets information from a database (in an array) and sends it to a JSON output.
From my PHP file (search.php) when I do this:
echo json_encode($items);
My output (when looking at the search.php file) is this:
["Example 1","Example 2","Example 3","Example 4","Example 5"]
Which is valid JSON according to jsonlint.com
The problem is that when I use jQuery UI's Autocomplete script to reference the external search.php file, Chrome just gives me the following error:
GET http://www.example.com/search.php?term=my+search+term 404 (Not Found)
I have tried inputting the JSON code straight into the 'Source:' declaration in my jQuery, and this works fine, but it will not read the JSON from the external PHP file.
Please can someone help?
Here's my code:
HMTL
<p class="my-input">
<label for="input">Enter your input</label>
<textarea id="input" name="input"
class="validate[required]"
placeholder="Enter your input here.">
</textarea>
</p>
jQuery
$(function() {
$( "#input" ).autocomplete({
source: "http://www.example.com/search.php",
minLength: 2
});
});
PHP
header("Content-type: application/json");
// no term passed - just exit early with no response
if (empty($_GET['term'])) exit ;
$q = strtolower($_GET["term"]);
// remove slashes if they were magically added
if (get_magic_quotes_gpc()) $q = stripslashes($q);
include '../../../my-include.php';
global $globalvariable;
$items = array();
// Get info from WordPress Database and put into array
$items = $wpdb->get_col("SELECT column FROM $wpdb->comments WHERE comment_approved = '1' ORDER BY column ASC");
// echo out the items array in JSON format to be read by my jQuery Autocomplete plugin
echo json_encode($items);
Result
In browser, when information is typed into #input
GET http://www.example.com/search.php?term=Example+1 404 (Not Found)
Update: the real PHP url is here: http://www.qwota.co.uk/wp/wp-content/themes/qwota/list-comments.php?term=Your
Please help!
UPDATE: ANSWER
The answer to my problem has been pointed out by Majid Fouladpour
The problem wasn't with my code but rather with trying to use WordPress' $wpdb global variable as (as far as I understand) it includes it's own headers, and anything outside of it's usual layout will result in a 404 error, even if the file is actually there.
I'm currently trying to get around the problem by creating my own MySQL requests and not using WordPress's global variables / headers.
PS. Majid, I'll come back and give you a 'helpful tick' once StackOverflow lets me! (I'm still a n00b.)
Are you sure the path source: "http://www.example.com/search.php" is correct?
You have to make sure that the target URL exists. If you are really using http://www.example.com/search.php then, wk, it simply does not exist, so this is why it does not work.
Update
Since you have a real URL that's working (I tested it!), here are a few steps you can take:
Make sure there's no typo. If there's one, fix it.
Make sure you can open that URL from your browser. If you cannot, then you might be having network access problems (firewall, proxy, server permission issues, etc.)
Try redirecting to another know URL, just to make sure. The 404 error is really a "not found" error. It cannot be anything else.
I think the include is the issue. As Majid pointed out... use the below include instead.
include("../../../wp-load.php");
Good luck!
Your apache server is sending wrong headers. Here is a pair of request and response:
Request
GET /wp/wp-content/themes/qwota/list-comments.php?term=this HTTP/1.1
Host: www.qwota.co.uk
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: __utma=142729525.1341149814.1305551961.1305551961.1305551961.1; __utmb=142729525.3.10.1305551961; __utmc=142729525; __utmz=142729525.1305551961.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Response headers
HTTP/1.1 404 Not Found
Date: Mon, 16 May 2011 13:28:31 GMT
Server: Apache
X-Powered-By: PHP/5.2.14
X-Pingback: http://www.qwota.co.uk/wp/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Mon, 16 May 2011 13:28:31 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Response body
["Bake 'em away... toys.","Content precedes design. Design in the absence of content is not design, it\u2019s decoration.","Hanging on in quiet desperation is the English way.","I'm a reasonable man, get off my case.","Look at me, Damien! It's all for you!","Never get out of the boat... absolutely god damn right.","That gum you like is going to come back in style.","The secret to creativity is knowing how to hide your sources.","Things could be different... but they're not.","Your eyes... they turn me."]
So, even though you receive back response from the server, it has HTTP/1.1 404 Not Found in the headers. Someone may be able to investigate this and provide a potential reason and solution.
I am experiencing a strange behaviour of my application in Chrome browser (No problem with other browsers). When I refresh a page, the cookie is being sent properly, but intermittently the browser doesn't seem to pass the cookie on some refreshes.
This is how I set my cookie:
$identifier = / some weird string /;
$key = md5(uniqid(rand(), true));
$timeout = number_format(time(), 0, '.', '') + 43200;
setcookie('fboxauth', $identifier . ":" . $key, $timeout, "/", "fbox.mysite.com", 0);
This is what I am using for page headers:
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Thu, 25 Nov 1982 08:24:00 GMT"); // Date in the past
Do you see any issue here that might affect the cookie handling? Thank you for any suggestion.
EDIT-01:
It seems that the cookie is not being sent with some requests. This happens intermittently and I am seeing this behaviour for ALL the browsers now. Has anyone come across such situation? Is there any situation where a cookie will not be sent with the request?
EDIT-02:
Here are the HTTP Headers:
Request Method:GET
Status Code:200 OK
REQUEST HEADERS
Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Referer:http://fbox.mysite.com/dashboard
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/532.5 (KHTML, like Gecko)
Chrome/4.1.249.1045 Safari/532.5
RESPONSE HEADERS
Cache-Control:no-cache, must-revalidate
Content-Length:8903
Content-Type:text/html
Date:Tue, 06 Apr 2010 09:25:26 GMT
Expires:Thu, 25 Nov 1982 08:24:00 GMT
Last-Modified:Tue, 06 Apr 2010 09:25:26 GMT
Pragma:no-cache
Server:Microsoft-IIS/7.5
X-Powered-By:PHP/5.3.1 ZendServer
Thanks again, for any guideline.
The only thing I can think of, having seen your header information, is that PHP is outputting something before you set the cookie. If that is the case, setcookie should return false and you'll get a warning "Cannot send session Cookie - headers already sent" As Bart S. suggests, turn on error_reporting(E_ALL) and try outputting the return value of setcookie to verify this isn't the case.
Also, try just using setcookie in the basic case with just a name and value and check the response headers again. Then cut out all of your code except for the setcookie and if that works, bring all your code back using divide and conquer :)
One question, one suggestion -
Question - why are you doing the number_format(...) on the time(), since a time() + 43200 should be sufficient.
Suggestion - Have you looked at the clocks between the client and the server. Since you're only giving a 12 hour difference between the two, if there is a big clock skew or a disagreement on when GMT is between the two machines you might find that you're sending a cookie that is destine to expire in the very near future.
The way you handle your cookies is completely fine, everything seems okay in your code, the problem seems to lie with Chrome.
Although Chrome Issue# 3014 deals primarily with a Java applet, it seems that's what you are experiencing.
I've seen an issue similar to this before. I would double-check to see if the path is correct.
I'd imagine a www.domain.com is different from domain.com , as is www.domain.com/ (with trailing forward-slash)
Beyond that, check that PHP has access to write it's sessions to file with proper write permissions (it's a different directory depending on distro, but phpinfo() should tell you what directory it is trying to use. )
I've run into both of these before. The first one gives no error and seems to mimic what you're experiencing, the second one gives a file-write-access error of some sort but if errors aren't displayed you might not see that.
Is your application served from the http protocol or file:// ?
Chrome does not store cookies with local apps, and that's by design. You can change this behaviour with the command line switch:
--enable-file-cookies