I recently started getting the following error displayed in Firebug:
XML Parsing Error: no root element found Location: http://dd.example.com/1.0/sources/30 Line Number 1, Column 1: 30:1:1
What causes it and how do I fix it?
Headers tab:
Request URL: http://dd.example.com/1.0/sources/30
Request Method: PUT
Remote address: 11.11.111.111:80
Status Code: 204 No Content
Version: HTTP/1.1
Request Headers:
Host: dd.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://dd.example.com/
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 33
Cookie: _ga=GA1.2.1885184115.1475238275; PHPSESSID=7ggri150scu2g5et1f7gtone94
Authorization: Basic TEljaGGlcDqTdW5zaKfrZX==
Connection: keep-alive
Request Body:
name=name&value=Remote+Sock&pk=30
Response Headers:
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Content-Length: 0
Content-Type:
Date: Sun, 05 Feb 2017 16:59:50 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.
Sending Status Code 204 yet trying to send content.
Related
I'm encountering problems after moving my project management tool to a new server. There is a checkbox on the project list page which when enabled hides all project with the status of complete and writes an entry in the config table of the database (HIDE_COMPLETE_PROJECTS) and then reloads the project list page after the AJAX post is successful. However, after moving the site to another server, changes are made to the hange_hide_completed_status.php. database but the project list page does not reload, it seems that no response is being sent back from the server. Not sure if it makes a difference but my old server had php 5.2,17, the new one has 5.4 installed. Also the version of jquery is very old (1.4.4). I thought I might have a problem with compression, so disabled mod_deflate on the new server, but this didn't help. Interestingly if I call the php file change_hide_completed_status.php directly from the old site, I get non-printing characters and on the new site, firefox won't display the page due to a content encoding error. I think there is a problem with the server configuration/the content type but I can't get any closer.
Here is the code:
function changeStatus(checkboxStatus){
if (checkboxStatus.checked){
hide_status_value =1;
}else{
hide_status_value =0;
}
$.ajax({
type: 'POST',
data: {'hide_status':hide_status_value},
url: 'change_hide_completed_status.php',
cache:false,
success: function(response) {
window.location.reload(true);
}
});
}
<?php
include_once ("/var/www/sdtm/etc/config.php");
$status = $REQUEST_DATA['hide_status'];
$d = new PhPagaDbData;
$fields = array('HIDE_COMPLETE_PROJECTS' => $status);
$key = 'HIDE_COMPLETE_PROJECTS';
$fields = array('cfg_value' => $status);
$r = $d->update('config', $fields, 'cfg_key = ?', $key);
exit;
?>
HTTP response old server:
POST /sdtm/change_hide_completed_status.php HTTP/1.1
Host: mccosh.de
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://mccosh.de/sdtm/projects.php
Content-Length: 13
Cookie: PHPSESSID=d2b013669f1268af1cf516e60ae20c75
Authorization: Basic c2VjcmV0OnNlY3JldA==
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
hide_status=0
HTTP/1.1 200 OK
Date: Tue, 30 Dec 2014 11:04:13 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 220
Keep-Alive: timeout=5, max=8
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
HTTP response new server:
http://192.168.148.180:12323/change_hide_completed_status.php
POST /change_hide_completed_status.php HTTP/1.1
Host: 192.168.148.180:12323
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.148.180:12323/projects.php
Content-Length: 13
Cookie: PHPSESSID=4pj4md762cm2n1efqm5kljuse2; shellInABox=942508454:111011010
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
hide_status=0
HTTP/1.1 200 OK
Date: Tue, 30 Dec 2014 10:39:16 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u5
Content-Encoding: gzip
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 23
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
So now I am feeling silly: the application uses it's own gzip compression which was screwing everything up. After disabling this, everything was fine.
I have many redirections within a VM webserver, which work when browsing the server with the embedded navigator (iceweasel). But that does not work when accessing the server from the hosting machine's browsers (tested with FF4/IE8/Chrome/Opera11).
All experienced redirecting methods are driving to a "server not available or overloaded" in the hosting machine browsers.
If you could have a look to the headers from the apache logs and give some hints about the differences (main one looks to be the GET url, provided that the same code is operating):
Working request leads to this log :
cat /var/log/apache2/access.log | grep 127 | grep random | tail -n1
127.0.0.1 - authuserid [26/Jun/2011:11:11:52 +0200]
"GET /index.php?page=100 HTTP/1.1" 200 49151
"https://www.mydomain.foo/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=c0117685e7e65a307989c219efc587b4&sid=n7en2it41h2gumrcq3kmmil3c0&sidf=.ps_AWDkIY"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2011050718 Iceweasel/3.0.6 (Debian-3.0.6-3)"
Non working request leads to this log :
cat /var/log/apache2/access.log | grep 192 | grep random | tail -n1
www.mydomain.org:80 192.168.X.Y - authuserid [26/Jun/2011:11:08:07 +0200]
"GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=685de8bcd4d198d6ad7f3cf4b23de5b7 HTTP/1.1" 302 -
"http://www.mydomain.foo/index.php?page=xyz"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
I can't show the header response as I don't get a response and no error reported by apache (loglevel=error).
Thx
Controls done :
I have increased the browsers timeout (FF: network.http.keep-alive.timeout to 3600s : no change.
I checked that no headers were sent previously to the redirection : ok (a dump of headers_sent() shows no headers sent nor blank line or space in the includes, )
I have increased the Apache server timeout just in case: no change
I made sure of using an absolute url as of HTTP/1.1.
I tried php, html meta and js redirect: no change
EDIT 1:
Here are the headers as seen by LiveHTTPHeaders in the "non working" case :
http://www.mydomain.org/menus/noeud4.php
POST /menus/noeud4.php HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 3600
DNT: 1
Connection: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID=4bge5gg1rgkit78k3seqlfcbq2
Authorization: Basic aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ==
Content-Type: application/x-www-form-urlencoded
Content-Length: 98
login=my_superlogin1&pwd1=vbigpass3xqz%40A2L&captcha=91690& source=noeud4.php&>formulaire_valide=SOUMETTRE
HTTP/1.1 302 Found
Date: Sun, 26 Jun 2011 14:17:27 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 >mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3
X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
Content-Length: 0
Keep-Alive: timeout=60
Connection: Keep-Alive
Content-Type: text/html
http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 3600
DNT: 1
Connection: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID=4bge5gg1rgkit78k3seqlfcbq2
Authorization: Basic aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ==
HTTP/1.1 302 Found
Date: Sun, 26 Jun 2011 14:19:59 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 >mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3 X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Content-Length: 0
Keep-Alive: timeout=60
Connection: Keep-Alive
Content-Type: text/html
EDIT2:
Comparing both cases of request/responses (working/not working), I isolated the following 2 main differences among others :
On the "working" responses :
Status : 200
which I don't have on the "non working" reponse, but I do not understand why.
on the "NON Working" response :
DNT:1
which stands for the option Do Not Track (me) from FF4.
So I tried to deactivate this option, but same result.
I may miss sthg for sure. All looks as if the server was down. Maybe the session cookie (76 kb) is too big. I also tried downgrading firefox 4 to 3.6 as this another changed parameter, but I still get the same response with FF3.6 as FF4.
As you can see in the requests you posted you try to hit:
http://www.mydomain.org/menus/noeud4.php
but you get redirected to http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 and then again to https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Does it keep sending out 302 headers?
I'm guessing the noeud4.php script is some login script that will likely create a session and probably set some cookies. My guess would be to check if that is being done correctly - and figure out why it's throwing the 302.
Im using FireFox's HTTP Live headers to view the headers.
I wrote a script at mydomain.com that just sets a test cookie.
I thought that when we send a request to a naked URL, http://mydomain.com/script.php, cookies are sent across to all sub-domains.
But when I sent a request to http://www.mydomain.com/script.php, the cookie wasnt sent in the header request by the browser. How come ?
http://mydomain.com/script.php
GET /script.php HTTP/1.1
Host: mydomain.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8pre) Gecko/20100710 Ubuntu/9.10 (karmic) Namoroka/3.6.8pre
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
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 16 Jul 2010 00:08:11 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.2.11
Set-Cookie: UserID=23; expires=Fri, 16-Jul-2010 01:08:11 GMT; path=/
Content-Encoding: gzip
----------------------------------------------------------
http://www.mydomain.com/script.php
GET /script.php HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8pre) Gecko/20100710 Ubuntu/9.10 (karmic) Namoroka/3.6.8pre
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
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 16 Jul 2010 00:08:24 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.2.11
Set-Cookie: UserID=23; expires=Fri, 16-Jul-2010 01:08:24 GMT; path=/
Content-Encoding: gzip
----------------------------------------------------------
Is it that the newer browser aren't sending the headers like before ?
Add the domain option, domain=.mydomain.com. This corresponds to the domain parameter of setcookie, and this is explained there:
"To make the cookie available on all
subdomains of example.com then you'd
set it to '.example.com'."
Here is the request and response headers
http://www.example.com/get/pdf
GET /~get/pdf HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
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
Referer: http://www.example.com
Cookie: etc
HTTP/1.1 200 OK
Date: Thu, 29 Apr 2010 02:20:43 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: Me
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Cache-Control: private
Content-Disposition: attachment; filename="File #1.pdf"
Content-Length: 18776
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
----------------------------------------------------------
Basically, the response headers are sent by DOMPDF's stream() method.
In Firefox, the file is prompted as File #1.pdf. However, in Safari, the file is saved as File #1.pdf.html.
Does anyone know why Safari is appending the html extension to the filename?
I'm also using Kohana 3, serving the PDF from a controller method.
From what i see the content type is incorrect, i believe if that is fixed, your problem will be solved.
I've fixed it by adding die(); after streaming it
$dompdf = new DOMPDF();
$dompdf->set_paper("a4", "portrait");
$dompdf->load_html($html);
$dompdf->render();
$dompdf->stream($invoice.".pdf");
die();
Because you're telling it that it's HTML. Fix your MIME type.
Content-Type: text/html; charset=utf-8
You can change how Kohana 3 sends headers like so...
$this->request->headers['Content-Type'] = File::mime($file);
Firebug shows a request which causes a huge delay to
http://reboltutorial.com/wp-content/themes/minaflow/none
Details below but I don't understand why it says it comes from xmlrpc and the stylesheet:
Date Sun, 04 Apr 2010 16:10:02 GMT
Server Apache
X-Powered-By PHP/5.2.13
X-Pingback http://reboltutorial.com/xmlrpc.php
Expires Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control no-cache, must-revalidate, max-age=0
Pragma no-cache
Set-Cookie wordpress_test_cookie=WP+Cookie+check; path=/; domain=.reboltutorial.com
Last-Modified Sun, 04 Apr 2010 16:10:03 GMT
Vary Accept-Encoding
Content-Encoding gzip
Keep-Alive timeout=2, max=94
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=UTF-8
Requêtemise en page impression
GET /wp-content/themes/minaflow/none HTTP/1.1
Host: reboltutorial.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,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
Referer: http://reboltutorial.com/wp-content/themes/minaflow/style.css
1) Please remove SESSION_ID and all cookies from post (it's quote easy for hacker to access to your site with that)
2) In CSS you have 3 times next code:
background: url(none);
That's why it goes to 404 error!