I'm developing a Linked Data application and I need to use 303 URIs for my dataset. Currently, I have a dataset of 22500 .jsonld files with URIs as follows:
http://example.com/project/resource/file.jsonld
And I want to redirect browsers looking for text/html content to:
http://example.com/project/page/file.html
Which are not semantic files, so they are more readable.
Does anyone know how can I do this with Apache 2.4.10? I've been considering the type-map files, but I was wondering if there are another more efficient solutions than creating 22500 .var files.
Look at W3C: Best Practice Recipes for Publishing RDF Vocabularies. Although it is about publishing vocabularies, it lists a number of recipes for configuring content negotiation on Apache that apply equally to datasets.
The other key documentation for doing this is Apache Module mod_rewrite.
Related
I'm using nginx/1.10-3 and apache2-2.4.25-3 on Debian.
For many reasons i won't go into, I'm looking to switch to NGINX from Apache2.
My CMS has many files that either have no extensions, or have the wrong extension in terms of lining up with mime.types.
With Apache2 we rely on mod_mime_magic to override the extension and use the magic bytes to correctly set the content-type. However, I can't seem to find a way to get this on NGINX.
For example, we have images that end in .img and some files with no extension at all.
The only solution I can come up with, is to integrate extension rewriting/adding into the platform and change the extensions on upload and go through the existing ones. This will take a lot more time, though.
Is there a "hack" or an alternative to mime magic with NGINX?
Thanks
The SO post here explains what mod_pagespeed does, but I'm wondering if I would notice any significant difference in page load time with this installed on a server that is already using mod_deflate to compress files.
If it is worth installing, are there any special considerations to take into account with regards to configuration when running both modules, or should one replace the other? The server is running EasyApache4.
Yes you will because these modules do different things.
mod_deflate handles data compression
The mod_deflate module provides the DEFLATE output filter that allows
output from your server to be compressed before being sent to the
client over the network.
Simply put, its sole purpose is to reduce the amount of bytes sent for your server regardless of what kind of data is sent
mod_pagespeed performs optimizations that would speed up the resulting webpage performance from end user's perspective by following a bunch of web pages optimization best-practices
Here's a simple example:
imagine we have 1 html page and 1 small external javascript file
if we use mod_deflate, both of them will be gzipped BUT the browser would need to make 2 HTTP requests to fetch them
mod_pagespeed may decide it's worth inlining the contents of this js file into the .html page
if we use mod_deflate together with mod_pagespeed in this case the resulting number of bytes downloaded would be the same BUT the page would render faster as it would need to make only 1 single HTTP request
Such optimizations of the original .html page and its dependent resources may have a huge difference in terms of execution time especially on slow mobile networks
So the idea is to always enable mod_deflate and either apply these best-practices manually or use mod_pagespeed which would apply them automatically
I was just doing some testing with YSlow and it's telling me:
Grade F on Compress components with gzip: There are 10 plain text
components that should be sent compressed
I know that Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate, and so the easiest solution to remedy this is to use mod_deflate on an Apache 2 server.
However, I've checked with two shared hosting companies and one local company and they've all told me that they don't support mod_deflate.
I know that some older browsers have trouble accepting gzipped / deflated content, and I'm not suggesting it be enabled by default, but are there any negatives for making mod_deflate available? Is it just extra load on the server's processors?
Also, are there any alternatives? I saw that if you are using a CMS like Wordpress you could potentially install a caching plugin which would serve out gzipped cached versions of the pages initially generated via PHP.
Compression takes CPU time. Maybe the hosting company decided they care more about CPU than network traffic. Maybe they offer it with a more expensive package. MAybe they simply didn't add it. Only your hosting company would know.
When using PHP you can check whether your PHP setup has zlib support enabled. If that is the case you can use ob_start("ob_gzhandler"); in code to enable an output buffer which will compress your data or set zlib.output_compression in your php configuration for instance by using php_flag zlib.outout_compression on in your .htaccessfile.
http://php.net/ob_gzhandler
http://php.net/zlib.output-compression
Is it possible to send pre-compressed files that are contained within an EARfile? More specifically, the jsp and js files within the WAR file. I am using Apache HTTP as the web server and although it is simple to turn on the deflate module and set it up to use a pre-compressed version of the files, I would like to apply this to files that are contained within an EAR file that is deployed to JBoss. The reason being that the content is quite static and compressing it on the fly each time is quite costly in terms of cpu time.
Quite frankly, I am not entirely familiar with how JBoss deploys these EAR files and 'serves' them. The gist of what I want to do is pre-compress the files contained inside the war so that when they are requested they are sent back to the client with gzip for Content-Encoding.
In theory, you could compress them before packging them in the EAR, and then serve them up with a custom controller which adds the http header to the response which tells the client they're compressed, but that seems like a lot of effort to go to.
When you say that on-the-fly compression is quite costly, have you actually measured it? Have you tried requesting a large number of uncompressed pages, measured the cpu usage, then tied it again with compressed pages? I think you may be over-estimating the impact. It uses quite low-intensity stream compression, designed to use little CPU resources.
You need to be very sure that you have a real performance problem before going to such lengths to mitigate it.
I don't frequent this site often and I seem to have left this thread hanging. Sorry about that. I did succeed in getting compression to my javascript and css files. What I did was I precompress them in the ant build process using the gzip. I then had to spoof the name to get rid of the gzip extension. So I had foo.js and compressed it into foo.js.gzip. I renamed this foo.js.gzip to foo.js and this is the file that gets packaged into the WAR file. So that handles the precompression part. To get this file served up properly, we just have to tell the browser that this file is compressed, via the content-encoding header of the http response. This was done via a output filter that is applied to files that matched the *.js extension (some Java/JBoss, WEB-INF/web.xml if it helps. I'm not too familiar with this so sorry guys).
We're testing our ClickOnce deployed application internally on IIS (Internet Information Services), but we're wondering if we can deploy it to the wider internet using Apache on Linux so we can make use of our existing external website host.
If so, is there anything else I need to consider other than as specifying the correct mime types such as .application and .deploy?
I found a number of people asking the same question starting around 2005, but here is the first google result - also discusses silverlight.
http://software.clempaul.me.uk/articles/clickonce/
As far as I can tell, however, the only thing you would need to worry about would be setting up the mime types and providing access to the files.
The Paul Clement article is the best description I've found. I also came across a topic in the Apache documentation that suggests putting the configuration in the httpd.conf file instead of .htaccess files. Here are the lines I added to my httpd.conf file:
AddType application/x-ms-application .application
AddType application/manifest .manifest
AddType application/octet-stream .deploy