3 posts categorized "html"

12/18/2008

A Question for Visitors to This Site Using Internet Explorer

One look at this site and it is pretty clear that I'm no designer. I ran through some google analytics statistics for this month so far and was surprised to see that Internet Explorer only accounted for about one-third of the visits to this site. As it is a tech blog primarily focused on apache, tomcat, jboss and related items, maybe this isn't so surprising a statistic but today was the first time in the year that this site has been up that I visited it myself using Internet Explorer 7 and I have to say that this site looks terrible in IE.

I have no intentions of bashing IE or Microsoft here and I know I could spend some time trying to make the site work well across all browsers but the site pretty much looks the same as-is in Opera, Safari, Chrome and Firefox--only in IE do things look even stranger. This and the fact that approximately 35% of this site's visitors still use IE6 and IE7 has me wondering: Why DO technical users continue to utilize IE? I can understand if my visitors were typical Internet users but the focus of this blog and the search queries/referrals indicate that people visiting this site are looking for specific technical information, which implies "Developer", "System Administrator", "Webmaster", etc.—pretty much any one aware of the various rendering issues with Internet Explorer 7 and below.

If there is anyone out there visiting the site today and reading this particular post, if you could reply in the comments why you are satisfied with Internet Explorer as your main browser that would be really great.

Posted by Chris Mahns at 12:00 AM in browsers, frippery, html | Permalink | Comments (2) | TrackBack (0)

07/10/2008

Custom Errors in Apache

I came across this in the httpd.conf on the apache web servers for a major web site of ours.  The initial configuration had been hosted at a third party facility, then was brought in-house when the parent company purchased the firm that initially developed the web site.  Below is an example of the custom error page handler from this site:

ErrorDocument 404 /custom_errors/404.html
RewriteRule /custom_errors /webapp/path/404.html [R]

The first line sets the 404 custom error page to a page running on the local server.  The rewrite rule then issues a 302 redirect to the browser and tells the browser to pull the page from the web application path, (even though the page actually exists on the local filesystem as /custom_errors/404.html).  The only reason why I can think that the developer wanted this done was so that the page appears to be getting delivered from the same web application path that everything else was delivered from.

The main problem though with this kind of approach to custom error page handling is that you lose the 404 response code.  If ErrorDocument is set to 404 with a custom error page, apache still responds with a 404 - Not Found message but if you then issue a rewrite, then your browser receives a 302 redirect followed by a custom error page delivered with a 200 OK status.  This ultimately means that your custom error pages can get listed in search engines results pages (SERP).

We had one of these for 503 status codes too and it sure was interesting searching on Google for "name of the site +service interruption" and seeing how many valid links wound up getting listed with the "We're sorry. We are experiencing a service interruption" description.

The thing to keep in mind for web site administrators is that just because developers know ASP or JSP or whatever really well, it does not mean that they necessarily understand how the web and browsers work. If you see a custom 404 errors implemented as a jsp page, make sure that at the top of the source of that jsp page you see something like:

<html>
<head>
<title>404 - Not Found</title>
<% response.setStatus(404); %>
</head>
<body>
</body>
</html>

If it isn't there, get someone to put it there.  Otherwise, your business partners might wind up asking you why they are seeing the site's custom error pages showing up in Google's search engine result pges.

Posted by Chris Mahns at 12:00 AM in apache, browsers, html, siteadmin, sysadmin | Permalink | Comments (1) | TrackBack (0)

01/12/2008

Gripe: Absolute URL versus Relative URL

Ah FrontPage. You made it so easy to create web sites that there are many, **many** web site developers out there who do not know the difference between an absolute URL and a relative URL. I'm not talking about those cases when you need to link somewhere offsite--I'm talking about links to content that reside on your own site. Yes, this first post is a gripe. You would be surprised with how many times I come across this when we're going through a site. I once spent a couple of hours on the phone going over the differences between absolute URLs, relative URLs, and, of course, the server relative URL with a group of developers and I think by the end of the conversation, they were just saying "ok" to get me off the phone. What's wrong with using an absolute URL within your own site to link to your own content? Consider the following HTML for a fictional company's product manuals.


Absolute URL Example

a href="http://our.awesomesite.com/manual/index.html"> Product Manuals

Relative URL Example

a href="manual/index.html"> Product Manuals


Although both work and will result in loading the same page, the first will make troubleshooting problems with the web site a little bit tougher.

Consider the following example: our.awesomesite.com runs across a pair of web servers, serverA.awesomesite.com and serverB.awesomesite.com. A browser making a request for the homepage hits the load-balancer and the load-balancer sends that request off to one of the two real web servers. Now let's say that some of our customers are reporting an "intermittent" problem with one of the two web servers getting the manual. We operations-types fire up a browser and go to http://serverA.awesomesite.com/, (bypassing the load-balancer), and then click the link for the manuals. The trouble hits when we click that link. Due to there being an absolute URL, our browser gets sent back to the our.awesomesite.com address instead of going to the real server. If we experience a 404-Not Found error, we still don't really know which server is generating the error.


I understand that this example may be over-simplistic because since we assumed these were static pages, then we could just go to http://serverA.awesomesite.com/manual/index.html and see if we get an error and repeat the step for serverB. This becomes more annoying when there are dynamically-generated URLs and you have to go to the homepage, login, etc. Obviously, the scope of this article is geared towards web sites developed and running within the enterprise. Sites that are load-balanced because they have to be up. Sites that cost the company serious money when they are down.


Ditto for those base href's that some folks are so fond of. Avoid absolute URLs and base href's if at all possible.

Posted by Chris Mahns at 12:00 AM in gripe, html | Permalink | Comments (0) | TrackBack (0)