Blunder Dome Sighting  
privacy 
 
 
 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.



Click for Blog Feed
Blog Feed

Recent Items
 
DMware: OK, What's CMIS Exactly?
 
Document Interoperability: The Web Lesson
 
Cybersmith: The IE 8.0 Disruption
 
Cybersmith: The Confirmability of Confirmable Expe...
 
nfoWorks: IS 29500 (OOXML) Moving Ahead?
 
Cybersmith: Resources for .NET Interop
 
A Conceptual Architect Am I?
 
Cybersmith: Attributions for Code You Use
 
DMware: ODMA's Dark Matter
 
Cybersmith: No-friction Bits and Pieces

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2008-09-12

 

Cybersmith: IE 8.0 Mitigation #1: Site-wide Compatibility

I have been experimenting with Internet Explorer 8.0 beta 2 enough to realize that all of my own web sites are best viewed in compatibility mode, not standards mode.  I find it interesting that other browsers, such as Google Chrome, apparently apply that approach automatically, suggesting to me that the IE 8.0 standards mode is going to cause tremors across the web.

The first step to obtaining immediate, successful viewing under IE 8.0, as well as older and different browsers, is to simply mark all of my sites as requiring compatibility mode.  That is the least activity that can possibly work.  It provides a tremendous breathing room for being more selective, followed eventually by substitution of fully-standard versions of new and heavily-visited web pages on my sites. 

Some pages may remain perpetually under compatibility mode, especially since the convergence of web browsers around HTML 5 support will apparently preserve accommodations for legacy pages designed against non-standard browser behaviors.

This post narrates my effort to accomplish site-wide selection of compatibility mode by making simple changes to web-server parameters, not touching any of the web pages at all.

#0. The Story So Far
#1. The Simplest First Step That Can Possibly Work
  2.  Satisfying the Prerequisites
  3.  Experimental Approach for Confirming mod_headers Operation
  4.  Web Deployment Approach
  5.  Authoring the .htaccess File
  6.  Deploying the .htaccess File
  7.  Confirming .htaccess Success
  8.  Shampoo, Rinse, Repeat
  9.  Tools and Resources 

See also:
2008-08-30 Orcmid's Lair: Interoperability: The IE 8.0 Disruption for the situation and the basic approach
[undated] MSDN Library: Defining Document Compatibility, Internet Explorer 8.0 beta, preliminary
[undated] MSDN Library: Implementing the META Switch on Apache, preliminary
2008-08-28 Hanu Kommalapati: Apache httpd configuration for IE7 standard mode rendering in IE8 (via Bruce Kyle)

#0. The Story So Far

On installing Internet Explorer 8.0 beta 2, I confirmed that none of my web sites render properly using the default standards-mode rendering.  However, my sites render as designed for the past nine years if I view them in compatibility mode.

Although I want to move my high-usage pages to standards-mode over time, I don't want users of Internet 8.0 to have to manually-select compatibility mode when visiting my sites and their blog pages.

What I want now is the simplest step that will advertise to browsers that my pages are all to be viewed in compatibility mode.  This will direct the same presentation in IE8.0 as provided by older versions of Internet Explorer and and current browsers (such as Google Chrome) that don't have the IE8.0 standards mode.   I can then look at a gradual migration toward having new and high-activity pages be designed for standards-mode viewing while other pages may continue to require compatibility mode indefinitely.

#1. The Simplest First Step That Can Possibly Work

There are ways to have web sites define the required document compatibility without having to touch the existing web pages at all.  If I am able to accomplish that, I will have achieved an easy first step:

  1. Have a complete site automatically set to be browsed in compatibility mode (EmulateIE7, in my case), buying time to provide finer grain solutions.

This is accomplished by convincing the web server for my sites to insert the following custom-header line in the headers of every HTTP response that the server makes:

X-UA-Compatible: IE=EmulateIE7

The HTTP-response lines precede the web page that the web server returns.  The browser recognizes all lines before the first empty line as headers.  Everything following that empty line is the source for the web page.  The browser processes the headers it is designed to recognize and ignores any others.

You can see the headers returned as part of an HTTP request by using utilities such as cURL and WFetch.  Here are the headers from my primary web site using a show-headers-only request via the command-line tool, cURL:

Headers from http://nfoCentrale.com/ (click for full-size image)

2. Satisfying the Prerequisites

The MSDN Article on Defining Document Compatibility describes site-wide compatibility control for two web servers: Microsoft Internet Information Server (IIS) and Apache HTTP Server 1.3, 2.0, and 2.2.

  • Have direct access to the folders of web pages on my web server.
    Satisfied:
    I have FTP access to the complete set of directories that hold web pages for my sites.
      
  • Determine that my Apache web server is one of those discussed.
    Satisfied:
    My web-site hosting service uses Apache HTTP Server on Linux.  When I check the administrator control panel provided by the hosting service, I discover that I am on Linux kernel 2.6.9 and Apache version 2.2.9 (Unix).  The Apache 2.2 requirement is satisfied.
      
  • Determine that I can set server-level response.
    Not Satisfied:
    My sites (nfoCentrale.com and all domains that are added-on and shared under it) are on a shared server.  I do not have access to the overall server nor to the httpd.conf configuration file.

The Apache 2.2 Module mod_headers documentation and Hanu Kommalapati's example describe how directory-level response headers can be specified instead.

  • Determine that I can set directory-level response headers.
    Not Clear:
    I know that I can create .htaccess files everywhere on my sites.  I don't know whether mod_headers is installed in my server configuration.  This list suggests that the option is not available, and there might not even be dynamic loading of extensions (mod_so).   The easiest way to confirm the actual state of affairs is by experiment.
      
    To Be Verified: I also submitted a support ticket; the hosting company responded immediately.  The answer is, yes, mod_headers is supported on my server.  Great!  Now to see it working.

3. Experimental Approach for Confirming mod_headers Operation

  1. I want to introduce an .htaccess file that has the following content:

    <IfModule headers_module>
    Header set X-UA-Compatible: IE=EmulateIE7
    </IfModule>
      
  2. I will try it out on a site that is a placeholder with no meaningful content and no visitors other than myself: eoware.org.
     
  3. The current state of the site has the following default result when I direct IE8.0 beta2 to http://eoware.org:
     
    Unaltered eoware.org site as seen by IE8.0 beta 2 (default standards-mode) 
      
    This portion of the default page is shown in default standards-mode view.  Notice the broken-page button to the left of the refresh button.  This indicates that a compatibility-mode view is available.
      
    This rendering is not in agreement with how the page was designed (and not touched since 2006).  Notice the color of the horizontal line, and the (added) spacing in the right-justified revision-history information lines.
       
  4. When compatibility view is selected, the page appears as it was designed (non-standard as it is):
      
    Unaltered eoware.org site rendered in IE8.0 beta 2 compatibility view
        
    The compatibility button is depressed, the horizontal line is the proper deep-blue color, and the spacing of the right-justified revision-history information is as expected.
      
  5. The desired state is as in (4) but with no action needed from the user and with the compatibility-view button not presented.  This will confirm that, for this site, the EmulateIE7 mode has been specified and automatically honored by the browser.  Other browsers (such as the initial Google Chrome release and older versions of Internet Explorer) will default to this view regardless; the custom HTTP header is harmlessly ignored by older browsers.

4. Web Deployment Approach

Having direct FTP access to the web-page folders on my server, along with an out-of-the-way place to try out the change, is relatively safe.   Since I am placing an .htaccess file where there presently is none, it is feasible to (1) upload the file, (2) see if it works, and (3) quickly delete it if there is any failure.  Having succeeded in introducing .htaccess files for other purposes, I'm confident I can make the change correctly.

I'll not do it that way.  Instead, I will rely on my web-deployment-safety model and take advantage of the safety net it affords, even though I could do without it if all I wanted was experimental confirmation.  This is a cybersmith post, and I want to illustrate a disciplined approach that has more flexibility in the long run.  To see the result that could have been attained by using the direct approach, you can peek ahead to section 6, below, and the image just above it.

Here is the structure of safeguards that I employ to control updates to my sites, keep them backed up, and also have a way to restore/move some or all of the sites.  I can also roll-back changes that are incorrect or damaging.  I can repair a corrupted site too (and I have had to do that in the past).

  1. The hosted-site web-server pages are maintained using FTP between the server and a private development server which holds a complete image of the hosted-site content.  This mirror is in the file system of the development server (an old lap-top running Windows XP and connected on my household LAN for duty as a light-weight server).   Synchronization between the site and the mirror is accomplished by FTP in either direction, depending on where new content first appears (on the server for Blogger web logs, on the development server for manually-authored pages and their updates).
      
    Basic Site Deployment Setup.  The hosted-site is kept synchronized by FTP with a file-system image (left) on a private development server. The content of http://nfocentrale.com is mapped to the folder structure starting at public_html. The Visual Source Safe project $/A2HostingWeb provides source-code management, versioning, and backup of the public_html image (right).
    The hosted-site is completely mirrored  in the file system of the development server (click for larger image) VSS Project $/A2HostingWeb provides source control over the hosted-mirror public_html directory (click for larger image)

        
  2. In addition to being separately backed-up, the hosted-site image corresponding to http://nfocentrale.com is also the working folder of a Visual SourceSafe project, $/A2HostingWeb.  VSS holds the current and also older versions of site material.  VSS is also the source of newly-authored material that is ready to be added to the image and published to the hosted-site itself.
       
  3. At the web-site, the eoware folder under public_html (the http://nfocentrale.com top level) has also been defined as the top level of the eoware.org domain.  This is accomplished by use of the hosting-service administrative control panel to create an add-on domain (of an already-leased domain name) at a particular sub-folder of my main site.  This feature is a key factor in my choice of the particular hosting service.   In addition, the .htaccess file that I already have in public_html causes any access directly to the eoware/ folder to be redirected to use the http://eoware.org URL.  This forces the correct address in the browser for use in book-marking and in search results.  These two cURL requests demonstrate the mapping:
      
    The nfocentrale.com/eoware is the home location of eoware.org; access to the folder automatically switches to the eoware.org domain (click for larger image)  
      
  4. To use this deployment path, I need to author the desired .htaccess file and have it checked-into VSS under the $/A2HostingWeb/eoware/ project.  To deploy the new material, the content is exported (using Get Latest Version ...) to the file-system site-image location on the development server computer: c:\publicca\A2hosting\public_html\eoware\.  Transfer to the web site is by FTP synchronization of the site-image eoware\ folder and the corresponding hosted-site folder.
      
  5. Although this is a roundabout way to make this individual page, it maintains the practice of not ever authoring directly in the deployment path except under serious emergency.  In the absence of an emergency, all development-site authoring occurs elsewhere and is brought under VSS management first.  New and changed material flows from VSS to the site image to the web site.

    Some new material and changes do originate on the hosted site first.  Typical site-first materials include blog posts originated from Blogger and Windows Live Writer, wiki pages (whenever that day comes), and data gathered from web-page forms.  Those materials are also periodically synchronized from the hosted-site to the site image and then checked into VSS, keeping a complete site image on the development server under VSS management and for backup.

5. Authoring the .htaccess File

If I was simply making an .htaccess page, I would create it directly in a text editor, having a file such as that created in step 4, below.  That page would be saved at a convenient location-machine address and then transferred to the hosted-site using FTP, leading to the result in section 6.

To preserve my development and deployment model, I require more steps. 

  1. Although I also have a development web site on the development server, it is an IIS server, not an Apache HTTP Server.  The IIS server, FrontPage 2003, and the FrontPage Server Extensions that I use to perform web-page authoring do not permit editing of Apache .htaccess pages and their automatic inclusion under source-code management. 
       
    I cling to this web-page authoring model not merely because I have used it since 1998, although that's reason enough.  I place high value on the development web-site pages being kept under automatic source-code management using Visual Source Safe.  I use the sharing feature of VSS to share the development-site web page content into the $/A2HostingWeb project too.  This permits staged synchronization between the development site, the hosted-site image, and indirectly the hosted site itself; and, vice versa.  (For those wondering what's on the quiz, I call this a hybrid Microsoft Site Server model, because it works in both directions to also capture authored material that arises initially on the hosted site.)
      
  2. Because .htaccess files and other Apache-site administration files need to be introduced under source-code management some other way than via FrontPage and my development web site, there's an administrative skeleton project, $/A2HostingAccount, that mimics the folder structure of the hosted-site image just enough to carry any administrative files. 
      
    Working Project for Authoring Adminstrative Files. Project $/A2HostingAccount holds administrative pages that are shared to the hosted-site via $/A2HostingWeb (left). Working folders under the local c:\MyProjects\A2HostingAccount directory provide check-out and editing of the .htaccess file (right).
    VSS $/A2HostingAccount with the eoware/.htaccess addition (click for larger image) MyProjects\A2HostingAccount Working Folder with eoware\.htaccess for authoring (click for larger image)

      
    The $/A2HostingWeb folder structure is replicated in $/A2HostingAccount only to the levels where .htaccess files appear.  The same .htaccess file is shared between a folder of $/A2HostingAccount and the same folder of $/A2HostingWeb.  In this way, $/A2HostingWeb has source-code management of the entire hosted-site image and $/A2HostingAccount provides a view that is limited to the administrative material.
      
  3. Because I already have some .htaccess pages for my server, I have lifted an existing one (from nfoworks) by sharing it to eoware, branching it so that changes don't reflect back to nfoworks, and sharing the newly-branched one to $/A2HostingWeb/eoware/ (so that changes will also be seen in that project).  This pattern will be re-used to quickly make more .htaccess pages for the root folders of my remaining web sites that need one as part of IE8.0 mitigation. 
      
  4. The customization of the new .htaccess file is accomplished by performing a VSS Get Latest Version ... operation of the eoware project to the working folders on my local machine (on the right, above).
      
    The next step is to open the local .htaccess copy in a VSS-aware editor and check out the file (or check it out first otherwise).  The checked-out version is edited to customize it for the new destination, adding the IE8.0-mitigating mod_headers instructions.
      
    After editing is complete, the changed file is saved to disk and checked-in via VSS control.
      
    This is the completed result:
      
    The eoware.org .htaccess after editing and check-in (click for larger image)

6. Deploying the .htaccess File

Having edited the .htaccess file on my development machine and checked it into VSS (on the development server), the next steps are all conducted on the development server:

  1. Using VSS on the development server, I perform a Get Latest Version ... operation on the $/A2HostingWeb/eoware project.  This delivers the newly-customized .htaccess file to the hosted-site image, the working folders for $/A2HostingWeb there.
      
  2. Using WS_FTP Pro on the development server, I connect to the hosted site.
     
  3. After connection, I drag the hosted-site image c:\publicca\A2Hosting\public_html\eoware\ folder to the connected-site /public_html folder in the WS_FTP connecting- and connected-site panes.  The eoware/ folder of the connected site is updated with any new or more-recent files from the hosted-site image.  I see that the .htaccess file is now there.

This is the same deployment procedure for updating of any of my individual sites under the hosted-site.  A script for it would be useful.  This is on my someday-not-now list.  Scripted or not, this is the basic procedure.

7. Confirming .htaccess Success

Assuming that the .htaccess introduction has not derailed the server, confirmation of the parameters and their success is straightforward:

  1. Access to eoware.org with the cURL utility should reveal the custom header in the response.  There it is:
     
    cURL request for eoWare.org headers confirms EmulateIE7 (click for larger image)
      
  2. Next, access to http://eoware.org/ with IE 8.0 beta 2 should provide a different experience.  And here that is:
      
    EmulateIE7 removes the Compatibility-View button and provides the compatible rendering
      
    This access automatically provides the compatibility view and there is no Compatibility View button.  (Compare with the second result in section 3.)

8. Shampoo, Rinse, Repeat

We've demonstrated that the .htaccess customization works correctly on my web site and provides the desired result on a little-used URL that is a placeholder for work yet to come.  After this cautious effort, it will be straightforward to add similar .htaccess files to each of the individual sites implemented on the hosted-site.  

Before that, I will first add the custom-header response to the .htaccess file that is already at public_html, the root of the main site, http://nfocentrale.com.   This provides the custom header for all access. 

Once all site access returns the custom HTTP header, I can then take my time determining how to work toward migrating sections of web sites to pages that view properly in IE 8.0 standards mode.  That will be accounted for as additional mitigation steps.

9. Tools and Resources

The following tools were used in this mitigation step:

  • cmd.exe, the Microsoft Windows XP command-line console shell
      
  • Hypersnap 6, for screen-shot diary and demonstration of the mitigation step
      
  • cURL 7.15.4, command-line HTTP request and response capture tool
      
  • Apache HTTP Server 2.2.9 (Unix), running as a shared server on a Linux web-hosting system
      
  • Windows XP computer for desktop development-site authoring
     
  • Windows XP computer providing the development web server (IIS), a co-located source-control database, and the hosted-site image for FTP synchronization with the hosting-service site
      
  • Visual SourceSafe 6.0d database on the same computer as the development web server
     
  • WS_FTP to synchronize directories without transferring unchanged material
      
  • jEdit 4.3 for editing the .htaccess page.  Any basic text editor can be used.  I use jEdit because (1) I already use it for other things, (2) it integrates with Visual Source Safe, and (3) it provides syntax highlighting for .htaccess files.

Labels: , ,

 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $