After updating Joomla to 3.8.1 today most of the admin tabbing and navigation functions stopped working in Chrome, FireFox, Win Safari, and IE 11. media/jui/js/bootstrap.min.js was failing to load with ERR_CONTENT_DECODING_FAILED. It still works in MS Edge.
This is occurring on machines in multiple locations and over multiple ISPs.
Actions taken (none of which have resolved):
Deleted file from server and replaced with backed up copy from last week and re-issued chmod 0644
Verified that public $gzip = '0'; in configuration.php
Tested in MS Edge where the error did not occur
Used MS Edge to go to Joomla Global Configuration > Server Settings and set Gzip Page Compression to No. Had been Yes.
Found that in browsers where it was failing if JS file is accessed without the versioning query string the browser can load file without error.
Found in Safari, IE 11, and iPhone Chrome the JS file displays and appears to be gzipped or otherwise encoded. Screenshot:
Cleared browser cache in Chrome
Went to chrome://net-internals and clicked Flush Socket Pools and Close Idle Sockets
Cache settings checked and it has been set to off the whole time:
System - Page Cache module also disabled
In this case the client had failed to mention they had added Sucuri Firewall service and that was where they corrupted cached file was being delivered from. Cleared cache at Sucuri and file no longer throws ERR_CONTENT_DECODING_FAILED
I had the same situation. Gzip on 0 in configuration.php did not work. So I found out that get_magic_quotes_gpc was deprecated in
libraries\src\Application\AdministratorApplication.php.
In my case I solved it by editing the default htaccess that my Joomla 4.2.X came with.
You have to leave these lines activated.
Header always set Cross-Origin-Resource-Policy "same-origin".
Header always set Cross-Origin-Embedder-Policy "require-corp".
And you have to remove this code:
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip
# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
Related
Its almost a week I'm having trouble with putting my node.js application online. I have a shared hosting where I created an subdomain (let's say sub.domain.com) and this subdomain is pointed to an directoy /home/wproj/myapp which contains code of my nodejs application. I logged into server using SSH and executed following commands exactly.
cd myapp
node index.js
Now node application is started on port 3000 but I cannot access its webpage from browser. so I used an .htaccess file which contains following code.
RewriteEngine On
RewriteRule ^$ http://127.0.0.1:3000/ [P,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ http://127.0.0.1:3000/$1 [P,L]
Now i can see the webpage at http://sub.domain.com/. But problem is my server is emitting an socket but client is not able to connect to that socket. On local server it was working perfectly fine, I don't seem to find any solution from hundreds of already asked questions I visited. In browser console, it says that
Firefox can’t establish a connection to the server at ws://sub.domain.com/socket.io/?EIO=3&transport=websocket&sid=pItfylCcSBwvBrGaAAAZ.
My client side code looks like this.
const socket = io.connect("http://sub.domain.com/");
I also tried entering port number like this
const socket = io.connect("http://sub.domain.com:3000/");
it didn't worked either. Also tried to replace 127.0.0.1:3000 with http://sub.domain.com:3000 and still socket is not connecting and always returns 404
I'm sorry for the long question, but I had to tell the whole story. If anyone can help me or point me in the right direction, I'll be grateful.
Thanks.
You need to have the port 3000 open for inbound and outbound traffic. Since it is a shared hosting you need to check if you can do this by yourself from the admin panel (cPanel for example) before writing a ticket to the support.
You can run this command grep -w 3000/tcp /etc/services to see if the port appears in the running services list.
You can investigate the network panel from Web Development Tools (Ctrl + Shift + I in your browser). If you see the No 'Access-Control-Allow-Origin' header is present on the requested resource. error then you need to start your server like this: io = require('socket.io')(httpServer, {'origins': 'sub.domain.com:*'})
I'm having trouble using the rewrite rules for Apache (2.4) to serve compressed files.
My javascript bundling process generate .gz files for every .js it creates. I've activated the rewrite module on apache a2enmod rewrite and set the .htacess file like this:
AddEncoding gzip .gz
RewriteEngine on
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch ".+\.(js\.gz)$">
Header append Content-Encoding gzip
Header append worked yes
</FilesMatch>
The problems I'm running are:
The first condition RewriteCond %{HTTP:Accept-encoding} gzip never evaluates to true. On Chrome Developer tools the client is sending this header Accept-Encoding:gzip, deflate, br (I've tried adding gzip, deflate, br to the condition but it doesn't work);
Even if I take this above condition out I can't see the header Content-Encoding in Chrome dev-tools;
I don't see Content-length in response headers. But it responds with a Transfer-Encoding:chunked which I find weird;
These are the modules that are enabled on my apache (I think they are enabled by default in my ubuntu dist because I didn't active any of those)
access_compat.load authz_user.load filter.load rewrite.load
alias.conf autoindex.conf headers.load setenvif.conf
alias.load autoindex.load mime.conf setenvif.load
auth_basic.load deflate.conf mime.load status.conf
authn_core.load deflate.load mpm_event.conf status.load
authn_file.load dir.conf mpm_event.load
authz_core.load dir.load negotiation.conf
authz_host.load env.load negotiation.load
The code you have there looks correct and seems to work fine on my computer, which suggests the problem is elsewhere. Some possibilities I can think of:
Perhaps a cache server/reverse proxy is messing with things (that would be my first guess, unless you're testing on localhost or set up everything yourself or otherwise know there isn't such a server)
Or perhaps mod_deflate is interfering anyways (I don't seem to have it installed on my computer so I can't test it); if you have access to the main server configuration maybe try commenting out the LoadModule line for it?
If any subdirectory has a .htaccess file that also uses rewrite rules, then rewrite rules in the parent directory won't run. (If this is the issue, RewriteOptions Inherit should work with these specific rules. However, this wouldn't explain the chunked encoding.)
Force refresh or clear cache in your browser?
I use Apache HTTP 2.4 as a reverse proxy. My configuration works fine except one thing:
I would like to change a string content (url) in an embedded JavaScript file
This is my actual virtual host configuration:
<VirtualHost web.mydomain.com:80>
ServerName web.mydomain.com
ServerAlias web.mydomain.com
DocumentRoot "..."
...
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
#Options -Indexes
#ProxyRequests On
#ProxyPreserveHost Off
# Web App
ProxyPass /hello http://middleware.mydomain.com:8082/hello-world-0.0.7
ProxyPassReverse /hello http://middleware.mydomain.com:8082/hello-world-0.0.7
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|hello-world-0.0.7|hello|ni"
</VirtualHost>
Could you please help me?
Usually, you should be able to configure the external URL in your application server, thereby eliminating the need to do the substitution in your Apache server. Such a configuration would be more efficient.
Did you validate in your browser that the returned Content-Type matches your filter? You indicate a Javascript file but filter for text/html. (e.g. Chrome: open Developer tools > navigate to the page > open Network tab > click on the resource that needs substitution > Look for the Content-Type header in the response headers). The Content-Type header should match your filter.
If it still does not work, it is likely that the application server returns gzipped content (check for Content-Encoding: gzip in the response headers). In that case, it makes sense that substitution won't work.
To work around that, add the following directive in your Apache configuration:
RequestHeader unset Accept-Encoding
Please note that this results in a performance penalty since more data needs to be sent across the network. I won't recommend this solution in a production environment since it applies to all requests for the current Virtual Host. If you only need to use substitution for a single file, I recommend wrapping the AddOutputFilterByType, Substitute and RequestHeader directives in a block, so that Apache only does the additional work for that file:
<Location "/hello/path/to/your/javascript/file.js">
RequestHeader unset Accept-Encoding
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|hello-world-0.0.7|hello|ni"
</Location>
I have a server running apache. The .htaccess contains the following:
<IfModule mod_headers.c>
<FilesMatch "\.(eot|ttf|otf|woff|css)$">
Header add Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
Why is it that
$.get('https://www.sarahlawrence.edu/_assets/v6/fonts/otama-text-regular/otamatextregular.eot')`
works (try it in the console from any domain), whereas
$.get('https://www.sarahlawrence.edu/_assets/v6/lib/icons.data.svg.css')
fails with this error:
XMLHttpRequest cannot load https://www.sarahlawrence.edu/_assets/v6/lib/icons.data.svg.css. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://whatever.com' is therefore not allowed access.
And how can I get it working?
The missing Header can be confirmed using curl:
curl -v https://www.sarahlawrence.edu/_assets/v6/fonts/otama-text-regular/otamatextregular.eot > delme.txt
curl -v https://www.sarahlawrence.edu/_assets/v6/lib/icons.data.svg.css > delme.txt
The regex should be happy with the filename so I expect that the problem is either because there is a conflicting configuration somewhere in the apache configuration.
Another diagnostic check would be to copy the failing file into the fonts directory and check whether the header is present - this will confirm that the regex or the filename isn't the problem but indicates that it is directory configuration related.
You have stated that there are no other .htaccess files in the document root or children ( this could cause the problem ) and the file is being served just without the headers.
My feeling at this stage is that this may be related to your mod_pagespeed which is disabled for lib/icons. It could even come down to the ordering of the modules being loaded.
Trivially I would first restart your apache just in case. Any caching or proxy infrastructure in between should be disabled. Next I would disable mod_pagespeed and see if the issue remains.
I would also check to see whether there is a block of configuration in either your httpd.conf or the virtual hosts configuration that is similar as it is possible that this is catching some directories and not others and that your .htaccess is not doing what is expected. As a further check I would try removing or temporarily renaming .htaccess ( to htaccess-removed or something similar ) to confirm that the URL request headers are no longer being included using the curl or other approaches to validating the CORS headers.
Probably not related however another thing I'd check is the permissions and ownership of the files and directories - thought worth mentioning just in case.
Also worth checking the error logs on restarting the apache and on making the requests as this may provide further insight.
What is the full path to your .htaccess file?
Ether your .htaccess file is not set up in a way to have it apply it's rules to files in the https://www.sarahlawrence.edu/_assets/v6/lib/ location, or there is another rule somewhere else superseding the rule you have shown above.
ok, i'm having so many problems with my custom template, it's not even funny ...
it's a custom template for joomla 3.x ...
one problem which i'm trying to figure out is where is the missing javascript request coming from?
i've unpublished all modules, and even uploaded a new template with some alterations ...
but it still persists!
if you view source and click on the supposedly missing file, it shows up fine ... so, why in javascript console in Chrome does it keeps saying it's 404!!!!!
how do you figure how where the request is coming from?
also, I keep seeing this in view source but no idea where it's coming from ...
<script type="text/javascript">
window.addEvent('load', function() {
new JCaption('img.caption');
});
</script>
EDIT ...
to make it clear what file I'm talking about, it's this one:
<script src="/social/services/templates/testingdifferentversion16/js/jquery-1.10.1.min.map.js" type="text/javascript"></script>
if you look at view source, you can access it fine.
if you see the error that it can't find it, hence the 404, the file is indeed missing.
that's why this post was written up, in order to find where that request is coming from.
hope this edit clears things up a bit.
EDIT 2 (as per morantis's request)
##
# #package Joomla
# #copyright Copyright (C) 2005 - 2013 Open Source Matters. All rights reserved.
# #license GNU General Public License version 2 or later; see LICENSE.txt
##
##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line just below this section: 'Options +FollowSymLinks' may cause problems
# with some server configurations. It is required for use of mod_rewrite, but may already
# be set by your server administrator in a way that dissallows changing it in
# your .htaccess file. If using it causes your server to error out, comment it out (add # to
# beginning of line), reload your site in your browser and test your sef url's. If they work,
# it has been set by your server administrator and you do not need it set here.
##
## Can be commented out if causes errors, see notes above.
Options +FollowSymLinks
## Mod_rewrite in use.
RewriteEngine On
## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.
## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects
##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##
# RewriteBase /
## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the request is for something within the component folder,
# or for the site root, or for an extensionless URL, or the
# requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
#user2730725 This drove me crazy a while back too! That file is a .map and is for debugging purposes only. Turn off the setting that tries to retrieve it by opening Chrome Dev Tools, then Settings and in General there is a checkbox for Enable JS source maps. Unselect it. Problem solved. :)
Check if there is a .htaccess file in the root directory and then check if there are mod_rewrite rules in that file. Many CMS packages use mod_rewrite to handle navigation through the site. If you are using a program like Filezilla for FTP, then make sure that the program has "show hidden files" set in the options or you may not even see the .htaccess file. if there is one, post its contents in your question.
I quickly looked and yes, Joomla does use a mod_rewrite to control flow in the website and there are multiple errors that come from this.
http://forum.joomla.org/viewtopic.php?f=304&t=346374
This is a link that is not exactly on par with your question, but it does give you the idea of how things can get messed up using .htaccess. Give me a little more info and we will go from there.
Alright, if you trying to access this file then it will have to be put directly in the address bar. If you look at the mod_rewrite rules, you will see that if the URL ends in a "/" or does not end in an extension, then it will have "index.php" added to the end of it.
Does that make sense?