I have set up a simple site for a design client at pub.regularsite.com where I put finished design projects.
The site is set using Apache directory listings with subdirectories for logos, flyers etc.
The problem is that the listing headers (name, last modified & size are in English and I would like them to appear in French.
Is it possible to specify the header language in the .htaccess file or elsewhere?
Is it possible to make it automatic, based on the user's system language?
Sorry, I don't think you can do this with the default directory-listing module that ships with Apache.
By default, directory listings are generated by Apache's mod_autoindex, which according to the latest version in the repository [1] does not have any translations for strings such as "Last modified" etc.
If you don't care about it being in the user's preferred language and just be in French all the time, I'm guessing that if you translate all the strings in that file, recompile the module, reinstall it and restart Apache, it'll do what you want -- although it's probably more work than finding some other directory generation tool out there with support for translations on a per-user basis.
[1] See http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_autoindex.c?revision=1705983&view=markup at line 1584: the "Last modified" string is hardcoded, does not refer to a dictionary of translations.
Related
I want to archive an old website which was built with PHP. Its URLs are full of .phps and query strings.
I don't want anything to actually change from the perspective of the visitor -- the URLs should remain the same. The only actual difference is that it will no longer be interactive or dynamic.
I ran wget --recursive to spider the site and grab all the static content. So now I have thousands of files such as page.php?param1=a¶m2=b. I want to serve them up as they were before, so that means they'll mostly have Content-Type: text/html, and the webserver needs to treat ? and & in the URL as literal ? and & in the files it looks up on disk -- in other words it needs to not support query strings.
And ideally I'd like to host it for free.
My first thought was Netlify, but deployment on Netlify fails if any files have ? in their filename. I'm also concerned that I may not be able to tell it that most of these files are to be served as text/html (and one as application/rss+xml) even though there's no clue about that in their filenames.
I then considered https://surge.sh/, but hit exactly the same problems.
I then tried AWS S3. It's not free but it's pretty close. I got further here: I was able to attach metadata to the files I was uploading so each would have the correct content type, and it doesn't mind the files having ? and & in their filenames. However, its webserver interprets ?... as a query string, and it looks up and serves the file without that suffix. I can't find any way to disable query strings.
Did I miss anything -- is there a way to make any of the above hosts act the way I want them to?
Is there another host which will fit the bill?
If all else fails, I'll find a way to transform all the filenames and all the links between the files. I found how to get wget to transform ? to #, which may be good enough. It would be a shame to go this route, however, since then the URLs are all changing.
I found a solution with Netlify.
I added the wget options --adjust-extension and --restrict-file-names=windows.
The --adjust-extension part adds .html at the end of filenames which were served as HTML but didn't already have that extension, so now we have for example index.php.html. This was the simplest way to get Netlify to serve these files as HTML. It may be possible to skip this and manually specify the content types of these files.
The --restrict-file-names=windows alters filenames in a few ways, the most important of which is that it replaces ? with #. This is needed since Netlify doesn't let us deploy files with ? in the name. It's a bit of a hack; this is not really what this option is meant for.
This gives static files with names like myfile.php#param1=value1¶m2=value2.html and myfile.php.html.
I did some cleanup. For example, I needed to adjust a few link and resource paths to be absolute rather than relative due to how Netlify manages presence or lack of trailing slashes.
I wrote a _redirects file to define URL rewriting rules. As the Netlify redirect options documentation shows, we can test for specific query parameters and capture their values. We can use those values in the destinations, and we can specify a 200 code, which makes Netlify handle it as a rewrite rather than a redirection (i.e. the visitor still sees the original URL). An exclamation mark is needed after the 200 code if a "query-string-less" version (such as mypage.php.html) exists, to tell Netlify we are intentionally shadowing.
/mypage.php param1=:param1 param2=:param2 /mypage.php#param1=:param1¶m2=:param2.html 200!
/mypage.php param1=:param1 /mypage.php#param1=:param1.html 200!
/mypage.php param2=:param2 /mypage.php#param2=:param2.html 200!
If not all query parameter combinations are actually used in the dumped files, not all of the redirect lines need to be included of course.
There's no need for a final /mypage.php /mypage.php.html 200 line, since Netlify automatically looks for a file with a .html extension added to the requested URL and serves it if found.
I wrote a _headers file to set the content type of my RSS file:
/rss.php
Content-Type: application/rss+xml
I hope this helps somebody.
I have a 1.7.9 SVN server exposed via Apache. It uses apache2-svn which allows to specify revision number as a part of the URL like this (for r65):
https://SERVER:PORT/REPO/FILE?p=65
I'd like to add a parameter to a query string that allows scrolling the file or even better - highlighting a range in the file. So users can send links pointing to "revision 65, lines 110-125".
Any ideas? The SVN stores only regular text files. Do browsers even support scrolling an arbitrary text file? Or would I need to transform the file into a HTML document? Any ready to use solution?
Cheers,
Pawel
Built-in Apache's SVN repository browsing feature is very simple and minimalistic. It does not allow you to specify the particular string to navigate to. The available URL syntax allows
viewing / downloading a particular file:
https://svn.domain.com/svn/MyProject/trunk/README.txt
viewing / downloading a particular file in revision 321:
https://svn.domain.com/svn/MyProject/trunk/README.txt?r=321
viewing / downloading a particular file, which is not available in the youngest revision, by specifying peg revision:
https://svn.domain.com/svn/MyProject/trunk/FILE_ID.DIZ?p=123
combining both of the above methods you can tune the view.
If you want more browsing features, install 3-rd party repository browsing UI. Take a closer look at ViewVC, WebSVN and Sventon.
How do I customize the list that web server does in absence of index.* file in the web root or its child directory, if we do not put any index files in the web root directory and the directory has the read permission?
you can set the page to show for a directory url with the index directive, it doesn't need to point to something called index.*, might just as well be whatever.html. See http://nginx.org/en/docs/http/ngx_http_index_module.html#index for details
or you can set autoindex on to give a generated file/directory listing, you can use the autoindex_exact_size and autoindex_localtime to further customize that listing. See http://nginx.org/en/docs/http/ngx_http_autoindex_module.html for details
3th option, if your nginx is compiled with it, is the random_index, see http://nginx.org/en/docs/http/ngx_http_random_index_module.html for details.
NOTE: to find out if your nginx is compiled with the needed --with-http_random_index_module option use the command nginx -V
Well, it depends on what webserver you are using.
In case of Apache, direcory indexes handled by a module called mod_autoindex.
When you want to customize the directory listing, then you have to know that Apache need three 'view' files:
The Header — by default automatically generated by Apache The
Directory Listing — necessarily generated by Apache
The Footer — referred to as the “Readme” file
The Header and Footer parts are basically written in plain HTML. The directory listing is generated by Apache but you can apply CSS on it..
The whole thing is a rather long story, so what I can suggest is a well written article with the details about this 'directory listing customisation':
Better Default Directory Views with .htaccess
If you follow the principle that an application should run "out of the box" when pulled out of version control, .htaccess should be included. Something doesn't feel right about that though, as it doesn't really feel part of the application. I'm conflicted, could someone put my mind at rest?
I typically do keep an application's .htaccess in source control which includes the Apache configuration required for the application to run, that is, rewrite rules which are not specific to the server it is running on, access to environment variables, etc.
Think about it this way - if the .htaccess file contains rewrite rules used by your application, those are effectively functioning as part of the application routing and therefore are part of the application.
If you are packaging an application for others to download and use, you should probably include a skeletal .htaccess file which includes the rules needed to make the application run. If your application is only intended to run on your own server and you keep all its relevant Apache config in .htaccess other than VirtualHost configuration, I would say it does indeed belong in source control.
This is a common problem for us, too, and I know what you mean about 'not feeling right'.
However, for me the issue is not about being feeling that .htaccess is not part of the application, as bits of it clearly are. The issue is more that that the file mixes application-specific code (routing, etc.) with installation-specific stuff (local URL rewrites, authentication/access rules, etc.). Ideally you would version control the application-specific rules but not the installation-specific rules, but of course this is not possible as both need to be in the same file.
I can think of four approaches to managing this. The optimal one will depend on your particular situation (and may vary from project-to-project):
Michael's second suggestion is the best option, if you control the deployments. Namely, keep application-specific code in the .htaccess file, under version control, and any installation-specific code in your main Apache VirtualHost directive. This gives full separation but is not a viable solution if you don't have direct access to the main Apache config or are distributing to third-parties.
Version control the application-specific elements of your .htaccess file, with clear comment markers, e.g. ### FOO APPLICATION SETTINGS - DO NOT CHANGE ### and ### ADD ANY ADDITIONAL LOCAL CONFIG BELOW THIS LINE #### and do not version anything that is installation-specific. This is fine if the rules are simple enough to not really cause conflicts, but is not great if your skeletal file requires users to modify existing lines, as you will likely end up with merge conflicts down the line. It also runs the risk of unwanted edits getting into your repository if deployments are version-controlled (as is probably the case for dev versions, at least) and it runs the risks of local changes being blown away by an upgrade if not (e.g. public zipfile distributions).
What we settled on as a good alternative is to version control a file called .htaccess.sample which can contain both application-specific rules and (where relevant) suggestions for installation-specific rules that users may find useful. This is easy to maintain and deploy whether or not version control is being used, but makes upgrades slightly harder as users will need to hand-merge any changes into their local .htaccess file. In our case, upgrades are always done by developers therefore this is not a big issue, assuming appropriate diff tools are available.
Same as #3, except you also provide a script to automatically apply any modifications. More work to set up, not necessarily more work to maintain, depending how you implement it (e.g. if it just replaces a block of code between some markers) and possibly worthwhile if you are distributing to a wide user base. This is what Wordpress does, for example.
I have our basic corporate static html website installed in our web root directory and our billing software installed in /portal. I have integrated the websites to look like a single site by including the /menu.tpl smarty template file in the /portal/header.tpl file. However, if I use relative URL's, the menu sysem doesnt work as the base url for the billing script is /portal. i.e. if I create a link to faq.php in the menu.tpl and I load a page on the portal site, the link in the menu back to the faq page is now /portal/faq.php whereby if I load a page off the root site the link is just /faq.php as it should be.
The obvious answer is to just use absolute URL's, but I need the site to be portable as I have many developers who need to install and test it.
I cant find anyway to resolve this. Any ideas?
I ran into the same problem as you a while ago, and after trying a lot of dead ends, I finally ended up with the following solution:
For any URL you need to be a chamelion, i.e. change its path depending on the environment, insert a PHP function that writes out the correct URL.
If you include the PHP function from a single central file, then you can change all of the URL's in the entire site automatically, based on a setting, or some pre-detected switch such as the current domain name, etc.
Example:
<?php print_base_url_plus("/menu.php"); ?>
... where print_base_url_plus() is a function which appends the base URL onto the output.
You may find that you have to change some of the URL's to be php, so they are preprocessed by the PHP engine, or, you can alter the web settings so that standard .htm files are piped through the PHP engine, just like .php files.