Hiking Mt. Moosilauke in Summer

Click to view photo gallery of this hike to Mt. Moosilauke!
This past weekend my wife and Ihiked to Mt. Moosilauke in the Western region of the White Mountains, New Hampshire. Trailheads start at the Dartmouth Outing Club's Ravine Lodge, on Rt 118 about 25 minutes from Lincoln, NH.

The Dartmouth College Ravine Lodge is an ideal starting point for a variety of hikes leading to Mt. Moosilauke. In summer, parking is freely available near the lodge. In winter, parking is available a mile away back at the Rt 118 entrance, and costs a few dollars.

Starting at the Ridge Trail trailhead, we completed a nine and a half mile loop that included the summit of Mt. Moosilauke. Ridge Trailto Beaver Brook Trail provides a less travelled and very scenic six mile route to the summit. The return trip can be made down Gorge BrookTrail or the Snapper Trail, each about three and a half miles. We completed the firstsix miles infive hours due to the ascent.Returning from the summitback down Carriage Trail and Snapper, the return to Ravine Lodge took just two hours.

Enjoy the photos!

See also:

Workaround for CFHTTP and Compressed HTTP Response from IIS

Some versions of IIS may use an HTTPCompression algorithm that is incompatible with ColdFusion (or Java in general). When using CFHTTP to performthe operations GET or POSTon the target website, if the target site is using Microsoft IIS with HTTP Compression enabled, the CFHTTP tag may report a Connection Failure. If the packets are traced with Ethereal, you might even see that all the compressed data is returned to the CFHTTP tag in the response, and the status code might even be 200 OK. If you are getting a Connection Failure result, the problem is that ColdFusion doesn't know how to deflate the compressed content. If this situation occurs, then you can specify additional headers to be sent with the CFHTTP request which tell the target webserver to disable compression for that response.


Correcting IIS 404 Page Not Found for URLs with ;JSESSIONID

When using ColdFusion MX while J2EE session variables are enabled, as defined in the ColdFusion Administrator, the session token jsessionid will be used to maintain state. If the application has planned for the possibility that clientside cookies are disabled for some users of the web application, then the application may have to use URLSessionFormat( ) to encode links within the application to maintain state by passing the session token in the URL. If so, the link URL's will have a semicolon delimited parameter appended to the url, in the format page.cfm;jsessionid=1234, for example. With the use of the semicolon in this manner, the jsessionid parameter is becomes part of the request path, not part of the request query string. Although this means of appending the jsession id into the URL is a J2EE standard, this URL format may confuse some webservers, including Microsoft IIS.

Microsoft IIS may report a 404 error for Page Not Found if the ;jsessionid parameter appears in the request URL. When using ColdFusion MX on JRun this can be corrected by setting the ignoresuffixmap property to false in the JRun connector stub configuration file jrun.ini. This file is typically found at the location {cfmx_home}/runtime/lib/wsconfig/1/jrun.ini or {jrun_home}/lib/wsconfig/1/jrun.ini. By setting this property to false, the JRun ISAPI filter will begin to match the URL for known extensions that should be handled by ColdFusion/JRun including *.cfm and *.jsp. When the JRun ISAPI filter matches the extension in a request it will pass the request to the JRun server without letting IIS further parse the URL for extension mapping.

Here is an example from the connector log of JRun ISAPI filter matching a request by the cfm extension, and properly handling the ;jsessionid parameter for the session:


The Race Condition of Conflicting SSL Certificate Stores

According the behavior I've observed today, a JVM loads one and only one SSL certificate store (keystore) at runtime. The JVM under ColdFusion comes with a default keystore having many popular SSL certificate types already imported into it. That default keystore is {cfmx}/runtime/jre/lib/security/cacerts. However, if you programmatically load a different keystore, then you will encounter a race condition where only one of the two certificate stores is loaded. The certificate store that gets loaded first is used by the JVM for all subsequent SSL connections. If the certificate stores have disparate certificates imported into them, then some SSL connections probably won't work and will vary back and forth every time the server restarts.


Error: Check JRun web server configuration and JRun mappings on JRun server.

Apache can be configured to connect to an instance of JRun at the global level and/or at the Virtual Host level. If configured at the global level, any Virtual Hosts will inherit the ability to connect to the globally-defined JRun server, and any JRun settings in the Virtual Host directive can override that of Apache's global level. If all the Virtual Hosts use the same JRun server as defined at the global level, then they will be configured for the same Serverstore and Bootstrap. In this way you can configure Apache for ColdFusion/JRun in a many to one relationship.


Small Gotcha with CFHTTP To SSL Enabled Web Sites

When connecting to an SSL enabled website using the CFHTTP tag in ColdFusion MX, be sure to lowercase the protocol https. Using the upppercase of the protocol HTTPS might cause the CFHTTP tag to hang until it times out, returning Connection Failure for the Status Code. I've seen some SSL websites work with CFHTTP when using a protocol as either uppercase or lowercase, such as HTTPS://login.yahoo.com, but I've seen others behave problematically.


More Linux Humor....

This had me rolling on the floor laughing....


CFQUERY in Site Wide Error Handler Does Not Escape Single Quotes for Error.DateTime

At last week's Boston CFUG presentation by Ben Forta, one audience member described a problem that has prevented them from migrating to ColdFusion MX from ColdFusion 5. The problem was that their custom error handler template wasn't working when configured as the Site Wide Error Handler template in the ColdFusion Administrator.

That ColdFusion user has since emailed me the error template and a description. The template attempted to present some error information to the user and then log all the error data by inserting it into a database with CFQUERY. The problem was that the error handler template rendered some of the error handling info to the client, but then instead of inserting the data the original error that first invoked the error handler was returned to the client. The client then saw a partial page with "Ooops, there's been an error" followed by the original error as if it were never handled.


CFERROR Bug: null null

During the general session at CFUN04 this weekend, a ColdFusion user asked a question regarding why "null null" error messages occur in ColdFusion MX. This is bug 51579 and the problem occurs when CFERROR is used for custom exception handling and a Null Pointer Exception occurs at runtime. This causes the cferror variable error.diagnostics to be populated with the value of "null null". Normally, error.diagnostics is the concatenation of cfcatch.message and cfcatch.detail, but during an NPE they each evaluate to null when cferror is used and so the result is "null null". If you know of any other way to generate this rather unhelpful error message and you have a small, exact reproducible case, then please let me know.

Update: This bug has a hotfix for CFMX 6.1 and CFMX 6.1 Updater 1:

Hot fix for null, null errors

Using Keytool to Import SSL Certificates into Sun JDK

I've recently seen a little discussion on CFTalk about importing SSL certificates into the JVM keystore used by the JVM under ColdFusion MX in order to connect to SSL enabled resources, such as LDAP servers or Web Servers while using either the tags CFLDAP, CFHTTP, or CFINVOKE. I've also found myself having to do this for the first time recently. During that process I stumbled on what turned out to be a bug in the JVM 1.4.2-b28 that ships with ColdFusion MX 6.1 by default.

I saved the SSL certificate to my ColdFusion directory runtime/jre/lib/security, as shown in this image. When using that JVM's keytool utility, described here in the Sun documentation, to import the certificate, I received an error indicating that the certificate which I exported from the SSL website was not valid, and I knew that was incorrect as someone else had just imported the same certificate their machine.