Apache mod_rewrite: rewriting URLs based on HTTPS vs. HTTP
On occasion it’s helpful to be able to pass both SSL and non-SSL requests through the same Apache configuration file. Using mod_write‘s RewriteCond and RewriteRule, you can perform URL rewriting differently depending on whether or not the connection is via HTTPS:
# For SSL connections %{HTTPS} is "on" -- the following will
# permanently redirect all non-SSL requests from remote sites to SSL
RewriteCond %{HTTPS} !on
RewriteCond %{REMOTE_ADDR} !127.0.0.1
RewriteRule (.*) https://example.com$1 [L,R=301]
The first condition is true if HTTPS is not on (the exclamation mark negates the condition). The second condition is true for any remote address other than 127.0.0.1. Since consecutive RewriteCond statements are AND’ed, the RewriteRule will only be applied to remote non-SSL requests and will permanently redirect (with HTTP code 301) all requests to an https address.
Keiahooooooooooooo!
When Lorrie offered to get me a Colts jersey last year, I had to pick a player. That’s when I saw Freddy Keiaho single-handedly (literally, since one hand was in a cast at the time) tackle both the blocker and the ball carrier in one fell swoop. I saw his passion and I knew that I could proudly wear a #54 jersey. Now every time Keiaho makes a tackle, we shout out “Keiahoooooo!” And by the end of a game, my voice is hoarse!
After sitting in our basement watching the Colts on the big screen break the curse of Lucas Oil Stadium with an awesome 31-3 win over Baltimore, Lorrie and I decided to go for a walk in our neighborhood. Lorrie said it was too hot to wear a jersey and took her Harrison jersey off, but I insisted, “I’m not wearing it for warmth, I’m a fan!”
Just as we rounded the corner of our neighborhood clubhouse, a car pulled up and a young guy leaned out of the window. “Hey there. I’m Freddy Keiaho!” It was really Freddy Keiaho, his wife, and a bunch of her sisters. They saw my jersey and pulled over to say hi.
Freddy asked if we have a pen… of course, we didn’t. So, they invited us to climb into the back of the car and they drove us to our house to get a pen. Unbelievable! Lorrie and I were very impressed with him. An incredibly polite young gentleman.
Woohoo! No washing this jersey!
Freddy Keiaho and a Freddy Keiaho fan
Traci, Freddy, Traci’s sisters and me
jEdit won’t start after OS X Java update
I noticed that jEdit would no longer start on my MacBook Pro with OS X 10.5.5. I’d try to run jEdit via Quicksilver as usual, but it wouldn’t open. Double-clicking on the jEdit application icon was just as useless. Nothing happened. I checked for anything that could be blocking it and restarted my laptop with no change. I upgraded to the latest version of jEdit but it still wouldn’t run.
It turns out that the latest Java update from Apple managed to break jEdit’s launch. After a decent amount of Googling, I ran into the solution. Basically, it involves replacing a symlink with its target.
rm /Applications/jEdit.app/Contents/MacOS/jedit cp /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub /Applications/jEdit.app/Contents/MacOS/jedit
And it even came with an explanation:
The basic problem has to do with symlinks to the latest java application stub. It used to be that you could symlink to the stub, so that you could use whatever was installed on the user’s system. Now it seems that there are some problems with the launcher looking for files in the wrong directory, and using the actual stub instead of a symlink is required.
I decided to copy it here just to improve the odds of finding a solution for the next person. Thanks to those folks who discovered & reported the solution.