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

> I didn't say everyone should switch.

So what exactly is "People still use Apache?" saying, because it looks an awful lot like an expression of surprise at there being a plural of person not having switched away from Apache yet.

> ...[waffle]...

Missing the point.

> switching out takes time and effort, but that doesn't mean you shouldn't do it.

That's precisely what it means: When one has a long list of tasks to achieve, the solution is basically to prioritise those tasks in terms of how much benefit they provide versus how much it costs to achieve them.

Those that wont benefit from switching or for whom it occupies too much time should not do it, unless either/both of those cases change.

Whilst there are sacrifices nginx makes in favour of performance, there will remain people who require functionality it does not provide, and Apache is likely to remain their best/only option for quite a while. Assuming they aren't in the ~15-20% that (OMG) don't use nginx or Apache.

If you're still reading anything here as superiority then I'm probably wasting my time, but at least it's making Truffles happy.

Its called a generalisation, with an emoticon to show mock surprise.

You can't simply cut out bits of my post and claim it's waffle. You need to show which bit is waffle and why.

Also, why does something taking time and effort mean you shouldn't do it? When you have a laundry list of tasks that you need to prioritise, investigating change should be in there. Not necessarily at the top, but to negate it entirely is foolish.

There's only one cure for nerd rage: disco.
http://youtu.be/u1qN6gLbUMw