I am using helmet: app.use(helmet()) and also tried adding app.disable('x-powered-by') for good measure to remove X-Powered-By headers.
The header is in fact removed on the html page that is generated but for files served from public using app.set('views', __dirname + '/views');it seems like the header is still showing up there. Is this normal behaviour? Is there a way to get rid of the header on those public files also?
For anyone running into the same issue. I found out that this was just due to the caching of css files on the browser... Simply opening and closing the browser seemed to have the X-POWERED-BY header being stripped out now.
Related
I am rather new to TYPO3. Recently I noticed some very weird behavior in my installation: Some CSS-files in the directory typo3temp/assets/compressed got the MIME-type text/html instead of the expected text/css. Therefore my browser received a 403 Forbidden status code from the webserver for these resources. That resulted in some parts of the backend being shown without styling.
I tried clearing all caches and deleting the typo3temp/assets/compressed directory, however now all the stuff in there (CSS and JS) is served with MIME-type text/html. Getting the backend without JavaScript means, that I am now basically locked out of the backend. I can however still reach and use the install tool.
Do you have any ideas how this might happen and how to fix it?
Some details of my setup:
TYPO3 v10.4.13 (recently updated from 10.4.9)
Apache web server (I don't have access to its config and have to rely on .htaccess files)
I suggest to set
TYPO3_CONF_VARS/FE/compressionLevel=0
TYPO3_CONF_VARS/BE/compressionLevel=0
in order not have these kind of problems. The problem is that this compression creates compressed files but relies on webserver configuration in order to deliver them as text/css and NOT applying the default webserver's transport compression to them (or they could end up double-compressed and you might not even easily notice - some browsers can deal with that, others not).
It is a kind of micro-optimization that sounded useful in times when we avoided https:// because of the processing overhead...
Here's some docs (the first statement is outdated in my oppinion): https://docs.typo3.org/m/typo3/reference-skinning/master/en-us/BackendCssApi/CssCompression/Index.html
I have a war with some static files (mostly images) in the webapp deployed on Wildfly. Sometimes the application needs to update some of those files, which then get replaced in the filesystem.
However Wildfly/Undertow seem to think that nothing has changed and the Last-Modified header in the response keeps showing the time before the update.
So I wonder what is Undertow using to determine the Last-Modified header shown. I've tried "touching" the parent directory, but to no effect.
In fact it looks like wildfly/undertow caches the last modified time after the first time it loaded a given resource.
Update
It's clearly a problem with the cache, since if I remove one of the files I requested before and request it again I get 500 Internal Server Error and stacktrace!
As pointed out in this thread the exploded war directory is not the right place for static resources that can be changed.
Instead one should use some other directory on the filesystem and configure the undertow subsystem to serve those pages. See for example this question.
I want to you Apache 2.2 httpd to SSI include URLs using
<!--#include virtual="/content/foo.html" -->
My problem is if, the SSI included page doesnt exist on my App server, it responds with a 404 response and a default error page HTML, which is then stitched into my page via the include.
For failing (4xx,5xx) SSI includes I simply want the SSI include to add the empty string to my page.
It doesn't appear Apache 2.2. supports the 'onerror' directive (which I think would solve this) - and i dont see any other options.
http://httpd.apache.org/docs/2.2/mod/mod_include.html
You could potentially add a rewrite to handle those portions of your application's URI space, but I'd advise against it. The approach being investigated seems to not fix the main problem: the concept of SSIs hinges on the files being included should be consistently available. If the included files are returning 4xx or 5xx class errors, the onus is on you to fix these errors.
Having this page Page, I can't seem to find a way to really disable the cache on all sides (server & client) .
What i tryed : disabled the network http cache on firefox from about:config(even cleared cache manually) ; added a timestamp in query string in the css url css/style.css?<?php echo time(); ?> ;
As you can see the style.css is empty but no changes are made to the page (unless i remove link tag , the css request) . I think apache cached the file and it's sending the cached version . How can i tell apache , via htaccess , not to send the cached version of the file and allways send it from the actual source path ?
P.S. : I'm working with a remote server .
Apache, in general, will not cache any content, unless you use mod_proxy_cache or similar.
Your caching is probably happening somewhere else. A few things to try:
see if you are using a proxy server, this can cache content sometimes
doing CTRL+SHIFT+R or CTRL+F5 usually forces the browser to refetch the content even if they already have the file in local cache
use Chrome's Network inspector or Firebug and check exactly which version of the file is being served and if the browser is sending the "If-Modified-Since" header and/or the server is sending the "Expires" header
You can also try setting the Expires directive in the Apache config, to force proxies/browsers to not keep stale copies of the file (https://httpd.apache.org/docs/2.2/mod/mod_expires.html).
If nothing else works, try renaming the file and see if it works. If it doesn't, your problem is somewhere else.
Using Apache with mod_rewrite, when I load a .css or .js file and view the HTTP headers, the Content-type is only set correctly the first time I load it - subsequent refreshes are missing Content-type altogether and it's creating some problems for me.
I can get around this by appending a random query string value to the end of each filename, eg. http://www.site.com/script.js?12345
However, I don't want to have to do that, since caching is good and all I want is for the Content-type to be present. I've tried using a RewriteRule to force the type but still didn't solve the problem. Any ideas?
Thanks, Brian
The answer depends on information you've not provided here, specifically where are you seeing these headers?
Unless it's from sniffing the network traffic between the browser and client, then you can't be sure if you are looking at a real request to the server or a request which has been satisfied from the cache. Indeed changing the URL as you describe is a very simple way to force a reload from the server rather than a load from the cache.
I don't think its as broken as you seem to. Fire up Wireshark and see for yourself - or just disable caching for these content types.
C.