I had a look in my (standard configurated) httpd.conf on my Apache 2.2 webserver and I was not able to identify what configuration is responsibly that gzip compression is working fine?
I searched for keywords like DEFLATE, AddOutputFilterByType or mod_deflate. But none of these keywords are in my httpd.conf.
Can anyone tell me, why compression works fine with the standard configuration? What configuration line is responsible for that?
You're looking for exactly the right thing, but you're probably not looking in all of your configuration files. You're probably using a multi-file layout, or looking in the complete wrong file.
Try looking for Include, or load mod_info to review the config that way in merged form.
I found the solution: A mod_deflate code in my .htaccess file in a subdirectory on my WordPress blog (Plugin WPSuperCache and Autoptimize) were responsible for the working gzip compression.
Related
What settings do I need to set in order to make Apache serve SVGs?
What I found:
These questions document the use of .htaccess to serve the SVGs with the correct MIME type "image/svg+xml" SVG images not displaying on certain web servers / https://mid.as/kb/00134/configuring-server-to-handle-svg-images / https://davidwalsh.name/serve-svg-image
This question handles the Requested URL not found
None of these helped resolve this issue.
Files:
.htaccess:
AllowOverride All
RewriteEngine on
AddType image/svg+xml svg
Folder structure:
Result:
Other:
Different files like .png work. I also tested it with Node (npx http-server) which worked.
AFAICR any recent version of Apache should have the SVG MIME type already configured. You shouldn't have to do it yourself unless you are running a very old version.
Anyway, a misconfigured MIME type wouldn't casue a 404. I think something else must be going on.
If you haven't already, try looking at the Network tab in your browser dev tools, and the Apache access log to check whether you are actually fetching the URL you think you are. And check that the file permissions are set correctly. Does the file have the correct owner, group, and permissions to be accessed by apache?
Apache 2.4 includes mod_proxy_html and that's great, it's catching all kinds of URLs inside the HTML coming back from the server and fixing them. But I've got a Seam app that sends back text/xml files to the client sometimes with fully qualified URLs that also need to be rewritten and mod_proxy_html doesn't fix them.
Apparently there was a mod_proxy_xml that used to exist separately from mod_proxy_html but Apache didn't include that. Is there a way to get mod_proxy_html configured to do the same thing? I need it to fix URLs in both the HTML and XML files coming back from a server.
Follow up:
I continue to fight with this and I've tried a few different solutions with no success including using mod_substitute (which somehow I'm configuring incorrectly because it never seems to substitute anything for anything) and using the force flag mod_proxy_html has to try and force it to do all files under a certain path.
This is an old question, but I just faced the same issue.
I tried with mod_proxy_html, compiled mod_proxy_xml, nothing worked.
#JonLin's suggestion is spot on, it works with mod_sed.
The only if is mod_sed is documented to work inside Directory nodes.
If you declare a Location though and do a SetOutputFilter instead of AddOutputFilter (which requires a mime type) it works beautifully.
The config that works is:
<Location "/">
SetOutputFilter Sed
OutputSed "s,http://internal:80,https://external.com,g"
</Location>
I am hosting multiple sites on the same server and using a http-vhosts file to specify virtual host info for them. It is working great. The problem is I changed in Movable Type the way entries are created. I want them to not have file extension. So it is currently domain.com/entry/15 instead of domain.com/entry/15.html. Because I took out the .html I'm assuming apache doesn't know what to do so it is spitting out the page as plain text. How can I fix this? I added in a virtualhost block:
DefaultType text/html
I also added that in the httpd.conf hoping it would fix it globally for all my sites. I restarted apache and still the same problem. Any ideas?
Is it possible that this is a content negotiation problem? In a few cases I've seen Apache try to determine what sort of file is being requested by looking at the first few bytes of the file being served.
I have seen problems like this be solved by commenting out mod_negotiation in http.conf and restarting. See the mod_negotiation documentation for more details.
I just solved the same issue by disbabling Magic Mime in httpd.conf (some files would display as html and some as text for no apparent reason).
edit /etc/httpd/conf/httpd.conf
Comment the lines for the Mime Magic Module:
MIMEMagicFile /usr/share/magic.mime
MIMEMagicFile conf/magic
Restart Apache and clear your browser cache
source
That seems correct. Care to share one link, or the HTTP headers that are returned for one of those pages? P.S. as well as the whole Apache config block where you placed that directive, for context?
if u create a .htaccess in ur site's root dir,and the .htaccess's content is:
DefaultType text/html
then the issue is fixed imm.
I'd like to make my server apply gzip compression to html, php, javascript and css files.
I think I can do it by editing the .htaccess file. Can someone give me the exact code that I would have to add?
Also, if I add the appropriate code to an .htaccess file in the parent directory, does it automatically apply to all sub-directories too? For instance, if I have http://domain1.com pointed at my root directory and http://domain2.com pointed at a sub-directory, will the second domain provide compressed files without me needing to edit the .htaccess file in that directory too?
Thanks
Use mod_deflate
More info here: http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
From the document that Peter Hall referenced on mod_deflate:
AddOutputFilterByType DEFLATE text/html text/css text/plain text/javascript application/javascript
And I believe that the answer is "yes" about the setting propagating down the directory tree to subdirectories. The best thing to do is check the response headers from the site (using FireBug or similar tool where you can watch the network traffic) and verify that the contents are compressed.
My server doesn't seem to gzip my css and javascript files. It works for HTML.
Here's my config: http://pastie.org/1105941
And here's my result: http://i35.tinypic.com/audv0k.jpg
Also tested Google Page Speed, and made Apache2 log the compression results. They say the same.
What could be wrong here, since it does compress the HTML?
As far as I can see, it is working ... using firefox and the webdeveloper plugin the response for both css and js reports gzip
Download a CSS file with a browers and check the content type. Chances are that it's application/binary or something. If that is the case, you must tell the server that *.css should be sent as text/css, etc:
AddType text/css .css