That first condition is redundant if index.html exists (the -f will get it), but if you want to do it as a safety/sanity check, I tend to do so as a distinct rule, like so:

RewriteRule ^index\.html                 -  [L]
RewriteRule ^(favicon\.ico|robots\.txt)$ -  [L]

Where the hyphen says "don't rewrite it".

The reason for having distinct rules being both readability and because despite being written first the rewrite conditions are checked after the first part of the RewriteRule is tested - so it feels better having distinct rules. (There'll be a (probably very minor) performance benefit too.)

I've not had problems with ErrorDocument - it is necessary to set it with cPanel, but all I do is this:

ErrorDocument 404 default
ErrorDocument 403 default
ErrorDocument 410 default
ErrorDocument 500 default

Don't remember if the order is relevant, but I have them after the RewriteEngine On line but before any rules are listed.

HTML5 History stuff is piss easy - just use this: https://github.com/browserstate/history.js/

There should be enough docs/examples/etc there to get it going, but I can probably answer questions if it misses anything.

People still use Apache? Oh.

Meow (cat)

Me to client: 'Why is your small, retail professional services web site that probably gets a half-dozen visits on a good day running on an apache server?'

Client: 'Huh?'

You should have said, "I can make your web site go faster"

 (fail)

I'm looking at the history.js, but it may be overkill and I'm reluctant to pile on another library. Anyhoo I may end up going down that road.

The tricky(er) part I've encountered is needing to do two seperate things: rewrite mydomain.com/ to mydomain.com/index.html (so ensuing ajax calls are bookmarkable), and mydomain.com/something.html --> mydomain.com/index.html#something

Simply chaining:

RewriteRule ^(.+)\.html?$ /index.html#$1 [R,L,NE]
RewriteRule ^$ /index.html [R,L]

throws it into a loop.
-----

Edit: hmmm, nope. After fixing a misplaced [L] flag, the htaccess seems to be working fine*. The loop was being caused by a js $.get statement which fails spectacularly (and mysteriously) if an include can't be found, in this case due to a misconfigured path, by 'get-ting' the entire index page instead, even though I was using a jqXHR .fail statement that works fine in other .get instances in my script. I managed to work out a kludge:

if ( !data.match(/^<DOCTYPE/) ) { [do the good stuffs] } else { FOAD }

*on my staging server...

The good thing about history.js is that it plugs in to several common libraries, but also has a native adapter.

Another workaround, if you're receiving a full page instead of a segment, is to pull out the html from the main content div, along the lines of:

if ( data.match(/^i) )
	data = $('div#content',data).html();

Not sure if it applies for your situation, but still a useful thing to keep in mind.

(fail)

More people use Apache then every other web server combined, and it has over twice the usage of the second most common server.

IF nginx continues to gain use at its current rate, it'll be 2020 before it has equal share to Apache.

I started out with a popstate listener which works fine except (I discovered) in IE11, so I switched it to hashchange, which seems to work equally well in all, relatively current browsers. So I guess I won't be needing history.js. Anyhoo, Tuesday I'll find out if my htaccess works on the client's server (it does have mod rewrite enabled).

I bet more people use Apache because somebody or something installed it for them and they are still using it and they don't know any better. That doesn't make it the best web server (for their needs).

Apache was the definitely the best at one time, but that was when there was nothing else worthwhile installing.

What makes nginx better apart from speed and resource handling?

It's not just a webserver, its also a really clever proxy server. You can use it to proxy anything (not just http, but any kind of tcp), from a frontend to a backend service really easily.

More importantly, it is asynchronous / event driven using 1 thread per CPU (core) , rather than using multiple threads/processes to handle responding to individual clients like Apache does, so it scales a lot better as well as being quicker.

Its not difficult to learn either, despite the nay sayers. The configuration format is different, but easier to learn than Apache's.

Good explanation. I currently use nginx on my RPis where required and Apache on my proper server(s). But they're not doing anything interesting, it was more a case of having used WAMP previously so I went with Apache when I moved my server to Ubuntu.

I only discovered how to use Proxies with Apache quite recently, really great idea in general. Passing specific subdomain requests to other servers seamlessly.

Apache gets the job done, and it's pretty much on all our client's low-cost shared web hosts. I never recommend that clients change their hosting, unless they are having major issues or our proposed solution can't work on it, then it's usually just to switch from IIS to Linux +apache (because those are the choices).

Maybe in future I'll be in a position to provision a more performant solution, where that's a requirement, and I'll consider the alternatives more carefully. I did install lighttpd on a virtual server recently and it was easier to bring up, and (seemingly) speedier than apache. But it doesn't appear to be available on any shared providers, so...

Thing is, since apache really is so widely used then going 'off the reservation', so to speak, could create problems for anyone who eventually inherits the server admin. So there's that.

Other thing I'm pondering is where containerization is going to take this whole business. I took a spin at it a few months ago, and it appears to be more geared to large-scale hosting providers.

Nginx has been available in Debian since 5.0 (I think) and Ubuntu since at least 12.04 and I'm sure the same is true of Redhat and other distros, so it's hardly going off reservation anymore. Installing and upgrading it is now no more difficult than installing Apache.

As long as you have free reign to install packages I would totally encourage you try it out and see what it can offer.

I might do that out of idle curiosity, one fine day.

 :-{)
 
Virtualbox. Hello?

Yes, and now the wonderful flawless nginx is around EVERYONE should instantly ditch Apache, all their years of experience, scripts, and configuration, and jump across to nginx which can be learnt instantly, provides all the same functionality, is perfectly compatible in every way, and will make scented rainbows shoot out their arse.

Or perhaps you could stop acting like a twattish fanboy and accept that they each have different benefits and drawbacks, and - even if nginx was objectively better in every way - it still takes time and effort to switch such a central piece of software, and so blurting about people "still" using what is by far the most used web server is simply pitiful.

I didn't say nginx was flawless and I didn't say everyone should switch.

Experience can be re-learnt, scripts re-written or better yet, written to be independent of the web-server, software and as for configuration, that should be handled by Saltstack or Puppet so you can test, re-test and deploy configuration changes safely. I know fully well that switching out takes time and effort, but that doesn't mean you shouldn't do it.

Also, I don't think nginx ships with the rainbow arse shooting module compiled in. Apache definitely ships with the false sense of superiority due to having more users module though :P

You two are funny