I am just getting started with setting up an app using Perl Dancer on Apache. I used the provided dancer script to setup my initial directory structure, and was able to get things setup to the point of seeing the initial "Perl is Dancing" page. Unfortunately, I noticed that the very end of the HTML markup is not included when I do a view source. Further investigation with Fiddler revealed the following error:
Content-Length mismatch: Response Header indicated 3,168 bytes, but server sent 3,364 bytes.
After seeing this, I did some additional experimentation, running the Dancer app directly via invoking app.pl from the command line. When I access that server, I get the full HTML markup and not content-length issues are reported by Fiddler.
Does anyone have any ideas why I may be seeing this incorrect content length issue when running through Apache? I should also mention that I am running through the generated CGI script that invokes app.pl via Plack::Runner. Please let me know if I need to provide additional details.
Dancer version is 1.3030 and Plack version is 0.9976.
It turns out that there was an issue with Plack. The revision history mentions "Fixed a CGI/FastCGI handler to ensure newlines are not mangled on Win32 platforms" for version 0.9977 (I failed to mention previously that I am running on Win32). I updated Plack to the latest version (currently 0.9978), and the problem went away.
Related
I was fixing things on a not well-maintained typo3 installation and it resulted in blank pages of frontend, backend and install tool.
I wanted to fix extensions because the powermail-extension was not working anymore even after updating to latest compatible version (tried emptying cache and database compare).
I deactivated an extension "compatibility6" to see if it was interfering and since then all pages have been blank including Install Manager. I reactivated the extension via PackageStates.php, emptied the cache but it did not change anything. I was not able to see any error messages even though I set the parameter in LocalConfiguration.php which made it hard to try to find out what is wrong. Then I restored a backup using vmware. Still, backend and frontend are blank.
I am using Apache and Typo3 7.6.23.
I do not know what might be causing the problem and would like to know what else to look for?
It means you have a PHP error there. The first thing would be to examine logs. If you see anything like "class not found", then your next action would be composer dumpautoload --no-dev.
Long time ago I had an article about blank pages in TYPO3 FE. Not up to date but still can be helpful: https://www.dmitry-dulepov.com/2009/03/blank-empty-page-in-typo3.html
Dmitry already wrote it: you have an error.
In production environment nothing is shown for not revealing any information about your system.
So the only information about the error can be found in the error log of your webserver.
What can you do to get more information about your error?
Enter the install tool and switch to develop mode. This will also enable deprecation logging into a file. Try to avoid filling your system with deprecation warnings by disabling deprecation logging.
Disable the default exceptionhandler by adding this to your typoscript setup:
config.contentObjectExceptionHandler = 0
Now you should see a call stack instead of blank screens.
Be aware that this might reveal confidential information from your system.
because of this you should use a copy of the live-system.
Good morning guys,
I just built a CentOS server with php 7.0.13 and apache 2.2 and the strangest thing is happening when testing it.
I had a curl script that works perfectly well through the command line but not when invoked through the browser, after investigating a bit, I realized that I can also not write to files if I do it through the browser, but I have no problem whatsoever doing it through the command line.
I assumed that the problem would be on two different php.ini files, but after verifying the phpinfo I realized that both the CL and the browser are loading the same, and all extensions seem to be loading correctly as well, by using get_current_user() I can also verify that the same user is executing both. I would assume the problem would be in apache, but I have no clue as to what could be causing it.
Can someone point out to possible avenues to solve the issue? I have no idea what to do from this point onwards.
As Hassan indicated the problem was with the user executing the script.
I commited an error thinking get_current_user() indicates the user executing the script, it does not, it indicates the file owner.
If you have a similar problem and need to figure who is executing the script use exec('whoami'); instead.
EDIT:Ok although that was one of the errors, the main error was on the fact that SELinux was activated, as soon as I deactivated the scripts started working perfectly.
In previous versions of AEM, certainly in CQ 5.6 and AEM 6.0, it was possible to tail the error logs over HTTP, without connecting to the server over SSH.
For example, I could get the last 1000 lines from the error log of my AEM author instance by calling:
http://localhost:4502/bin/crxde/logs?tail=1000
This seems to no longer be possible in AEM 6.2, this path does not resolve to anything.
Is there another way I could still tail the log over HTTP?
A colleague answered this question for me on a chat so I'm putting it here to make it easier to find in the future.
There's now a neat utility in the OSGi console that allows one to view the logs as well as configure the various loggers. You can find it at http://localhost:4502/system/console/slinglog
The Appender tab provides links to the various log files that can be used to load logs over HTTP.
Here's an example request it makes:
http://localhost:4502/system/console/slinglog/tailer.txt?tail=1000&name=%2Flogs%2Ferror.log
As you can see, both the log file name and the tail parameter can be specified. You can also use grep with both simple phrases and regular expressions.
This is a built-in feature of Apache Sling.
In addition FYI, you can also find the status-slinglogs where you can perform log file downloads in a zip and logger actions in a txt to your local at /system/console/status-slinglogs
http://localhost:4502/system/console/status-slinglogs
and the direct urls for the downloading these zip files are as below
http://localhost:4502/system/console/status-slinglogs.zip
http://localhost:4502/system/console/status-slinglogs/configuration-status-20170126-183246.zip (where as 20170126-183246 is and time stamp)
You should not be looking at log files via CRXDE lite.
log files in 6.2 are project specific - better to open them from a text editor.
see attached screenshot.
Hope this helps!
Regards,
Prince
You can curl the log with e.g.:
curl -u admin:admin 'http://localhost:4502/system/console/slinglog/tailer.txt?tail=4000&name=%2Flogs%2Ferror.log'
where 4000 is the number of lines you want to get.
I recently wrote a tool named "Log Tailer Plus" to solve exactly this problem. It's entirely free/open source - Take a look at a post describing usage here : https://blogs.perficientdigital.com/2019/05/14/introducing-aem-logtailerplus/
TLDR; You can grab an AEM package from here ( https://github.com/prftryan/LogTailerPlus ) install it to your machine, and access via http://localhost:4502/log-tailer-plus (if local) or http://server:port/log-tailer-plus
This tool will allow you to follow any number of logs at once by leveraging the out of the box logging endpoint(/system/console/tailer ) as well as dynamically checking active OSGI Logging Logger configurations. Currently, highlighting is supported, but only for relatively standard logging patterns (it's done via regex).
This is a new release, works on AEM 6.2+. Enjoy
I have a set of XSLT stylesheets that were working fine previously. Recently, a fellow developer upgraded our Perl to a newer version. Ever since that time, we have been getting intermittent stylesheet compilation errors where EXSLT functions are defined.
Here is an example of the error:
element param only allowed within a template, variable or param
The variable is defined within the EXSLT function. Once the error is received, I will get the error every time that I try to access my web page until I restart Apache (used in conjunction with mod_perl). After restarting, I can get the web page calling XML::LibXSLT and the EXSLT function to display properly once, but reloading the page will trigger the error again.
After reading the XML::LibXSLT docs, I have confirmed that the HAVE_EXSLT() function returns a value of 1. My current version of XML::LibXSLT is 1.79. My LibXSLT DLL is 1.1.28. My perl version is 5.14.3. The previous versions that worked were 5.8.8, 1.66, and 1.1.22, respectively.
Why am I now seeing these errors when I previously did not? Below is the beginning snippet from the stylesheet that is throwing compilation errors. Please let me know if there is any additional information that would be useful to provide.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:exsl="http://exslt.org/common"
xmlns:func="http://exslt.org/functions"
xmlns:dtbl="http://docbook.sourceforge.net/dtbl"
extension-element-prefixes="func"
exclude-result-prefixes="exsl func dtbl"
version="1.0">
<func:function name="dtbl:convertLength">
<xsl:param name="arbitrary.length"/>
Additional findings:
After my initial posting of this question, I discovered that I cannot reproduce the error at all if I use plain old CGI instead of mod_perl. Additionally, I found the following line in my Apache httpd.conf. When commenting it out, I saw that the frequency of the error occurrence dropped dramatically, although it did not completely remove the error.
PerlModule XML::LibXSLT;
From experience mod_perl does a lot of funny things for example JSON::XS works terrible under mod_perl and causes a serious memory leak + stuck process, so I moved to JSON::Tiny which is a native and simple code - which mod_perl can handle
I have a feeling that XML::LibXSLT has the same issue, I migrated my code from XML::LibXSLT to using native xsltproc for this reason, yes it requires spawning, but if you do it right, the overhead isn't worse that what you are doing now, and it is more stable
So my suggestion is to either move from XML::LibXSLT to xsltproc (binary) which I use under mod_perl without issues, or to find some other library to do the XSLT conversion for you (maybe FOP ? )
Is there a way to launch ColdFusion from the command-line?
I am not talking about launching the CF and related services with the net start command.
I remember doing this in the past. Basically, running CF from the command-line offered two advantages:
You didn't need to keep it as a Service and either have it always launch at boot-up or have to deal with the Services Manager
(more importantly) It echoed back to the screen all kinds of messages, especially error messages, which were helpful when actively developing (because you didn't need to go dig in the ColdFusion log files to find them)
It is possible that I'm mis-remembering and that this hasn't been available since ColdFusion 5.0. Is it at all possible with ColdFusion 9?
Update: Environment: Multi-server configuration with JRun.
Two ways to do this:
In development, add the server to ColdFusion Builder, and all the messages you talk about will show up in the console tab.
Start ColdFusion from the command line. The instructions are slightly different per environment but basically you want to get to bin directory and issue jrun start cfusion or coldfusion start or something similar . Post your environment for more specifics.
Go to C:\JRun\bin and issue jrun start cfusion
In your ColdFusion9/bin Folder you can find stop.bat and start.bat. Executing the latter gives you exactly what you want.