Log entries not displaying in Chrome console, are included in response header
brennydoogles opened this issue · 22 comments
While using Google Chrome 17.0.963.56 m Log entries created using ChromePHP do not display in chrome console. The ChromePHP extension is installed, and enabled for the page. Also, while looking at the response headers it appears that a base-64 encoded string containing the log data does exist. The only Javascript running on that page is JQuery and a simple function that acts upon specific named ul elements. Here are the response headers:
HTTP/1.1 302 Found
Date: Thu, 23 Feb 2012 16:42:33 GMT
Server: Apache/2.2.20 (Ubuntu)
X-Powered-By: PHP/5.3.6-13ubuntu3.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
X-ChromePhp-Data: eyJ2ZXJzaW9uIjoiMy4wIiwiY29sdW1ucyI6WyJsYWJlbCIsImxvZyIsImJhY2t0cmFjZSIsInR5cGUiXSwicm93cyI6W1siSW5mbyIsZmFsc2UsIlwvdmFyXC93d3dcL2xiYmRldlwvcHJvY2Vzc1JlZ2lvbkVkaXQucGhwIDogOSIsIiJdXSwicmVxdWVzdF91cmkiOiJcL3Byb2Nlc3NSZWdpb25FZGl0LnBocCJ9
Location: regionTree.php?message=success
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Are there any javascript errors? It's going to be tough to debug cause it works fine for me.
Oh! It might be because the page is a 302 redirect. I don't think logs are kept during a redirect. Can you try not redirecting the page and see if you get the log?
But this is a real problem... I have things I need to log during a request that ends with a redirect. In fact, this must be a common problem with any app/framework that uses the post-redirect-get pattern?
Is it a problem to capture the headers during a redirect and process them the same as during any other request?
Looks like onResponseStarted
is too late - would it work if you hook into onHeadersReceived
instead?
Okay, I don't really have any idea what I'm doing here, but I can't even get the current version to load in Chrome... it complains about the manifest version, so I updated that, and updated background_page
to match the new background: {}
schema:
"name": "ChromePHP",
"version": "3.0.1",
"manifest_version": 2,
"content_scripts": [
{
"matches": ["http://*/*", "https://*/*"],
"js": ["log.js"],
"run_at": "document_start"
}
],
"background": { "page": "background.html" },
It loads now, but all I see in the console now is Port error: Could not establish connection. Receiving end does not exist.
...
Any thoughts on fixing this issue? (if you have any pointers/ideas, I'd be happy to take another stab at it myself - just not sure where to start...)
@mindplay-dk I just rewrote most of the extension and pushed out version 4.0. I will look into capturing logs during a redirect soon.
Hi, I have similar problem (without redirect). Chrome console is empty and HTTP headers are fine.
Chrome version 28.0.1500.37 beta (tested on clean install) + Python (Django 1.5.1) connector.
The strange thing is that if I write this in PHP (copy-paste Django headers):
<?php
header('X-ChromeLogger-Data: eyJyb3 /* ... */ lwZSJdfQ==');
Everything is OK.
@illagrenan do you definitely have the extension toggled on (lighting up blue) for the current domain? I see that one is being requested on "127.0.0.1" vs. "localhost".
Try turning it on for 127.0.0.1
or going to http://localhost:8000
Yes, extension is 100% toggled on. First request (127.0.0.1:8000) is from Django internal server and second (localhost) from Apache (PHP).
I configured Django server to run on "http://localhost/", but console is still empty. If I access Apache on "http://127.0.0.1/_logger-test/", console shows "Hello console! ".
Hmm that is interesting. So you have tried both http://localhost:8000 and http://127.0.0.1:8000 for django and neither work? I am not sure what could be causing it. The header is there so it is clearly something with the extension or possibly another extension that is clearing the console.
To rule that out, try disabling all other Chrome extensions?
I disabled all the Chrome plugins, but console is still empty.
I discovered something new: when the response body is empty, everything works.
this:
# Working example in Django
def welcome_page(request):
console.log(request)
return HttpResponse()
results in:
and vice versa:
# Console is empty, body in response is present (Django internal server)
def welcome_page(request):
console.log(request)
return HttpResponse("Some text in response = console is empty")
<?php
// Console is empty, body in response is present (Apache)
header('X-ChromeLogger-Data: eyJyb /* ... */ ZSJdfQ==');
echo "Some text = console is empty";
In Chrome Settings there is an option under Console called "Preserve log upon navigation".
If you tick that your logs won't be erased through redirects...
Would it make sense to buffer the log entries, instead of outputting them, when the HTTP response is a 3xx redirect?
And then flush any buffered log entries upon the next HTTP 2xx response, prior to outputting the log entries from the 2xx response itself?
With post-redirect-get being very common in most web applications, this might make sense, as frequently the really important log-entries are generated during the redirect, when things are saved/updated (database queries, security/performance diagnostics, etc.) and not during the following successful response.
if response headers contains "Transfer-Encoding:chunked" then no console log. My php framework response chunked, but if i use a pure php script that response normal than i can get console output.
neaplus, i'm seeing the same problem but my response headers don't contain "Transfer-Encoding:chunked". I'm seeing the same behavior as illagrenan.
I am also facing the same problem. I am trying to display a single message using using ChromePhp::log('hello world') in my console but its not displaying anything.
Please help.
@maxxpower007 thank you sir, that fixed it for me!
I'm actually somewhat surprised that 6eb44d1 fixes some of the issues discussed above.
Does Chrome really trigger onResponseStarted
for 30#s and 204s?
Actually I think you are right @schmod. Probably fixes the issue that @illagrenan was reporting, but not the redirect issue. I will open a new ticket for that cause this thread was kind of a catch all