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.
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.
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.
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.
I think you'll find I can - see msg:41579.25 for an example.
> Also, ...[waffle]... to negate it entirely is foolish.
It seems I mis-judged when reducing; my original wording made it impossible to claim inferrance of that nonsense. Oh well.
Keeping abreast of the available options is a relatively simple task that all competent professionals do, and an entirely separate step from deciding whether any alternative should be even considered, nevermind actually testing it out and scheduling when a live implementation is viable and sensible.