Posts Tagged ‘Internet Explorer’

Chrome v. Firefox - The Container and The Desktop

September 4th, 2008 by smp | Comments | Filed in Browsers, Technology, The Web, Web Performance, Work

The last two days of using Chrome have had me thinking about the purpose of the Web browser in today’s world. I’ve talked about how Chrome and Firefox have changed how we see browsers, treating them as interactive windows into our daily life, rather than the uncontrolled end of an information firehose.

These applications, that on the surface seem to serve the same purpose, have taken very different paths to this point. Much has been made about Firefox growing out of the ashes of Netscape, while Chrome is the Web re-imagined.

It’s not just that.

Firefox, through the use of extensions and helper applications, has grown to become a Desktop replacement. Back when Windows for Workgroups was the primary end-user OS (and it wasn’t even an OS), Norton Desktop arrived to provide all of the tools that didn’t ship with the OS. It extended and improved on what was there, and made WFW a better place.

Firefox serves that purpose in the browser world. With its massive collections of extensions, it adds the ability to customize and modify the Web workspace. These extensions even allow the incoming content to be modified and reformatted in unique ways to suit the preferences of each individual. These features allowed the person using Firefox to feel in control, empowered.

You look at the Firefox installs of the tech elite, and no two installed versions will be configured in the same way. Firefox extends the browser into an aggregator of Web data and information customization.

But it does it at the Desktop.

Chrome is a simple container. There is (currently) no way to customize the look and feel, extend the capabilities, or modify the incoming or outgoing content. It is a simple shell designed to perform two key functions: search for content and interact with Web applications.

There are, of course, the hidden geeky functions that they have built into the app. But those don’t change what it’s core function is: request, receive, and render Web pages as quickly and efficiently as possible. Unlike Firefox’s approach, which places the app being the center of the Web, Chrome places the Web at the center of the Web.

There is no right or wrong approach. As with all things in this complicated world we are in, it depends. It depends on what you are trying to accomplish and how you want to get there.

The conflict that I see appearing over the next few months is not between IE and Firefox and Safari and Opera and Chrome. It is a conflict over what the people want from an application that they use all the time. Do they want a Web desktop or a Web container?

Tags: , , , , , , , , , , , , , , , , ,

IE 8 is coming…are you ready?

April 18th, 2008 by smp | Comments | Filed in Web Performance

So, Microsoft is releasing Internet Explorer 8 later this year, and a Beta is available now.

The question is, are you ready for it?

Internally, the tech savvy folks (myself included) have been tossing around the football of how to tackle it. The leap from 2 to 6 connections per host, on top of the basic rendering challenges that come with any new browser release are enough to make a Web team’s collective hive mind melt.

So, the bright team at Gomez are developing an IE 8 readiness kit.

Sounds like a great idea.

Why do you need to be concerned at a network level?

Let’s see…Well, while 6 simultaneous connections may be faster for clients, what happens to the TCP stacks of the devices that handle all of these connections, especially as more and more people start using IE 8?

Imagine that every Firefox user is using FasterFox, and then IE 8 comes along.

Do you have enough TCP sockets?

How quickly are sockets that are ready to be recycled actually recycled?

Are you really ready?

:-)

Tags: , , , , , , , ,

Dear Apache Software Foundation: FIX THE MSIE SSL KEEPALIVE SETTINGS!

June 6th, 2007 by smp | Comments | Filed in Software, Technology, Web Performance, WebPerformance.Org, Work

Dear Apache Software Foundation, and the developers of the Apache Web server:

I would like to thank you for developing a great product. I rely on it daily to host my own sites, and a large number of people on the Internet seem to share my love of this software.

However, it appears that you seem to want to maintain a simple flaw in your logic that continues to make me crazy. I am a Web performance analyst, and at least once a week I sigh, and shake my head whenever I stoop to use Microsoft Internet Explorer (MSIE) to visit secure sites.

I seems that in your SSL configurations, you continue to assume that ALL versions of MSIE can’t handle persistent connections under SSL/TLS.

Is this true? Is a bug initially caught in MSIE 5.x (5.0??) still valid for MSIE 6.0/7.0?

The short answer is: I don’t know.

It seems that no one in the Apache server team has bothered to go back and see if the current versions of MSIE — we are trying to track down the last three people use MSIE 5.x and help them — still share this problem.

In the meantime, can you change your SSL exclusion RegEx to something more, relevant for 2007?

Current RegEx:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive
	ssl-unclean-shutdown
	downgrade-1.0 force-response-1.0

Relvant, updated REGEX:

SetEnvIf User-Agent ".*MSIE [1-5].*"
	nokeepalive ssl-unclean-shutdown
	downgrade-1.0 force-response-1.0
SetEnvIf User-Agent ".*MSIE [6-9].*"
	ssl-unclean-shutdown

Please? PLEASE? It’s so easy…and would solve so many performance problems…

Please?

Thank you.

Tags: , , , , , ,

Tags: , , , , , , , ,

Internet Explorer: Plan to completely support RFC 2616 anytime before the next ice age?

March 13th, 2007 by smp | Comments | Filed in Technology, Web Performance

I am writing up a client presentation for next week, and I just realized just how flawed Internet Explorer is. Microsoft claims that the browser is standards compliant. Yet it still doesn’t support HTTP pipelining.

And the frustrating part? They won’t tell us why. I have my suspicions, which include TCP stack issues and a flawed HTTP handling mechanism that is still based on Windows 95 architecture, but an explanation from Redmond would be nice.

Every (and I mean every) other browser can do this.

Microsoft, it’s time you detached your Web browser from your OS, like you’ve forced everyone else to do.

Tags: , , , , , ,

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

Compressing Web Output Using mod_gzip for Apache 1.3.x and 2.0.x

October 3rd, 2006 by smp | Comments | Filed in Web Performance, WebPerformance.Org

Web page compression is not a new technology, but it has just recently gained higher recognition in the minds of IT administrators and managers because of the rapid ROI it generates. Compression extensions exist for most of the major Web server platforms, but in this article I will focus on the Apache and mod_gzip solution.

The idea behind GZIP-encoding documents is very straightforward. Take a file that is to be transmitted to a Web client, and send a compressed version of the data, rather than the raw file as it exists on the filesystem. Depending on the size of the file, the compressed version can run anywhere from 50% to 20% of the original file size.

In Apache, this can be achieved using a couple of different methods. Content Negotiation, which requires that two separate sets of HTML files be generated — one for clients that can handle GZIP-encoding, and one for those who can’t — is one method. The problem with this solution should be readily apparent: there is no provision in this methodology for GZIP-encoding dynamically-generated pages.

The more graceful solution for administrators who want to add GZIP-encoding to Apache is the use of mod_gzip. I consider it one of the overlooked gems for designing a high-performance Web server. Using this module, configured file types — based on file extension or MIME type — will be compressed using GZIP-encoding after they have been processed by all of Apache’s other modules, and before they are sent to the client. The compressed data that is generated reduces the number of bytes transferred to the client, without any loss in the structure or content of the original, uncompressed document.

mod_gzip can be compiled into Apache as either a static or dynamic module; I have chosen to compile it as a dynamic module in my own server. The advantage of using mod_gzip is that this method requires that nothing be done on the client side to make it work. All current browsers — Mozilla, Opera, and even Internet Explorer — understand and can process GZIP-encoded text content.

On the server side, all the server or site administrator has to do is compile the module, edit the appropriate configuration directives that were added to the httpd.conf file, enable the module in the httpd.conf file, and restart the server. In less than 10 minutes, you can be serving static and dynamic content using GZIP-encoding without the need to maintain multiple codebases for clients that can or cannot accept GZIP-encoded documents.

When a request is received from a client, Apache determines if mod_gzip should be invoked by noting if the “Accept-Encoding: gzip” HTTP request header has been sent by the client. If the client sends the header, mod_gzip will automatically compress the output of all configured file types when sending them to the client.

This client header announces to Apache that the client will understand files that have been GZIP-encoded. mod_gzip then processes the outgoing content and includes the following server response headers.

	Content-Type: text/html
	Content-Encoding: gzip

These server response headers announce that the content returned from the server is GZIP-encoded, but that when the content is expanded by the client application, it should be treated as a standard HTML file. Not only is this successful for static HTML files, but this can be applied to pages that contain dynamic elements, such as those produced by Server-Side Includes (SSI), PHP, and other dynamic page generation methods. You can also use it to compress your Cascading Stylesheets (CSS) and plain text files. As well, a whole range of application file types can be compressed and sent to clients. My httpd.conf file sets the following configuration for the file types handled by mod_gzip:

	mod_gzip_item_include mime ^text/.*
	mod_gzip_item_include mime ^application/postscript$
	mod_gzip_item_include mime ^application/ms.*$
	mod_gzip_item_include mime ^application/vnd.*$
	mod_gzip_item_exclude mime ^application/x-javascript$
	mod_gzip_item_exclude mime ^image/.*$

This allows Microsoft Office and Postscript files to be GZIP-encoded, while not affecting PDF files. PDF files should not be GZIP-encoded, as they are already compressed in their native format, and compressing them leads to issues when attempting to display the files in Adobe Acrobat Reader.[1] For the paranoid system administrator, you may want to explicitly exclude PDF files.

	mod_gzip_item_exclude mime ^application/pdf$

Another side-note is that nothing needs to be done to allow the GZIP-encoding of OpenOffice (and presumably, StarOffice) documents. Their MIME-type is already set to text-plain, allowing them to be covered by one of the default rules.

How beneficial is sending GZIP-encoded content? In some simple tests I ran on my Web server using WGET, GZIP-encoded documents showed that even on a small Web server, there is the potential to produce a substantial savings in bandwidth usage.

http://www.pierzchala.com/bio.html Uncompressed File Size: 3122 bytes
http://www.pierzchala.com/bio.html Compressed File Size: 1578 bytes
http://www.pierzchala.com/compress/homepage2.html Uncompressed File Size: 56279 bytes
http://www.pierzchala.com/compress/homepage2.html Compressed File Size: 16286 bytes

Server administrators may be concerned that mod_gzip will place a heavy burden on their systems as files are compressed on the fly. I argue against that, pointing out that this does not seem to concern the administrators of Slashdot, one of the busiest Web servers on the Internet, who use mod_gzip in their very high-traffic environment.

The mod_gzip project page for Apache 1.3.x is located at SourceForge. The Apache 2.0.x version is available from here.


[1] From http://www.15seconds.com/issue/020314.htm:
“Both Internet Explorer 5.5 and Internet Explorer 6.0 have a bug with decompression that affects some users. This bug is documented in: the Microsoft knowledge Base articles, Q312496 is for IE 6.0 … , the Q313712 is for IE 5.5. Basically Internet Explorer doesn’t decompress the response before it sends it to plug-ins like Adobe Photoshop.”

Tags: , , , , , , , , , , , , , , , , , , , , ,

IE7 — First Impressions == Uninstalled

May 2nd, 2006 by smp | Comments | Filed in Software, Technology

I installed IE7 Beta 2 tonight. It lasted 15 minutes.

What ended its stay? Opening a new tab crashed the application.

Let me know when: It. Just. Works.

There is likely some secret squirrel hack that fixes this. I don’t want to hear it. An application at this level of pre-release development should not encounter a bug as simple as this.

Technorati Tags: , ,

Tags:

eBay: It’s the Internet, not the Internet Explorer-net

October 4th, 2005 by smp | Comments | Filed in smp

Go sign the position asking eBay to make their Web site open standards compliant, instead of Microsoft-compliant. [here]

Via: Mozillazine

Tags: , , , , , , , , , ,

MSIE 6 and HTTP Compression — get the service packs!

September 30th, 2005 by smp | Comments | Filed in smp

A colleague in Germany forwarded me this interesting Microsoft knowledgebase article.


Internet Explorer May Lose the First 2,048 Bytes of Data That Are Sent Back from a Web Server That Uses HTTP Compression

This appears to only happen if another program registers (Real8 Download is the example given in the KB article) to use some of the more obscure Internet Name-Space handlers with Urlmon.dll. These corner cases include rarely used protocols like HTTP, HTTPS, and FTP.

Also, this only applies if you haven’t bothered to patch your MSIE 6 for like, oh, two years. So, if you have bizarre behaviour with sites that use compression, use that Microsoft Update thingie you may have heard of.

Tags: , , , , , , , , , , , , , , , , , , ,

Compressing Web Output Using mod_gzip for Apache 1.3.x and 2.0.x

April 30th, 2005 by smp | Comments | Filed in smp

Web page compression is not a new technology, but it has just recently gained higher recognition in the minds of IT administrators and managers because of the rapid ROI it generates. Compression extensions exist for most of the major Web server platforms, but in this article I will focus on the Apache and mod_gzip solution.

The idea behind GZIP-encoding documents is very straightforward. Take a file that is to be transmitted to a Web client, and send a compressed version of the data, rather than the raw file as it exists on the filesystem. Depending on the size of the file, the compressed version can run anywhere from 50% to 20% of the original file size.

In Apache, this can be achieved using a couple of different methods. Content Negotiation, which requires that two separate sets of HTML files be generated — one for clients that can handle GZIP-encoding, and one for those who can’t — is one method. The problem with this solution should be readily apparent: there is no provision in this methodology for GZIP-encoding dynamically-generated pages.

The more graceful solution for administrators who want to add GZIP-encoding to Apache is the use of mod_gzip. I consider it one of the overlooked gems for designing a high-performance Web server. Using this module, configured file types — based on file extension or MIME type — will be compressed using GZIP-encoding after they have been processed by all of Apache’s other modules, and before they are sent to the client. The compressed data that is generated reduces the number of bytes transferred to the client, without any loss in the structure or content of the original, uncompressed document.

mod_gzip can be compiled into Apache as either a static or dynamic module; I have chosen to compile it as a dynamic module in my own server (more compile instructions here). The advantage of using mod_gzip is that this method requires that nothing be done on the client side to make it work. All current browsers — Mozilla, Opera, and even Internet Explorer — understand and can process GZIP-encoded text content.

On the server side, all the server or site administrator has to do is compile the module, edit the appropriate configuration directives that were added to the httpd.conf file, enable the module in the httpd.conf file, and restart the server. In less than 10 minutes, you can be serving static and dynamic content using GZIP-encoding without the need to maintain multiple codebases for clients that can or cannot accept GZIP-encoded documents.

When a request is received from a client, Apache determines if mod_gzip should be invoked by noting if the “Accept-Encoding: gzip” HTTP request header has been sent by the client. If the client sends the header, mod_gzip will automatically compress the output of all configured file types when sending them to the client.

This client header announces to Apache that the client will understand files that have been GZIP-encoded. mod_gzip then processes the outgoing content and includes the following server response headers.

		Content-Type: text/html
		Content-Encoding: gzip
		

These server response headers announce that the content returned from the server is GZIP-encoded, but that when the content is expanded by the client application, it should be treated as a standard HTML file. Not only is this successful for static HTML files, but this can be applied to pages that contain dynamic elements, such as those produced by Server-Side Includes (SSI), PHP, and other dynamic page generation methods. You can also use it to compress your Cascading Stylesheets (CSS) and plain text files. As well, a whole range of application file types can be compressed and sent to clients. My httpd.conf file sets the following configuration for the file types handled by mod_gzip:

		mod_gzip_item_include mime ^text/.*
		mod_gzip_item_include mime ^application/postscript$
		mod_gzip_item_include mime ^application/ms.*$
		mod_gzip_item_include mime ^application/vnd.*$
		mod_gzip_item_exclude mime ^application/x-javascript$
		mod_gzip_item_exclude mime ^image/.*$
		

This allows Microsoft Office and Postscript files to be GZIP-encoded, while not affecting PDF files. PDF files should not be GZIP-encoded, as they are already compressed in their native format, and compressing them leads to issues when attempting to display the files in Adobe Acrobat Reader.[1] For the paranoid system administrator, you may want to explicitly exclude PDF files.

		mod_gzip_item_exclude mime ^application/pdf$
		

Another side-note is that nothing needs to be done to allow the GZIP-encoding of OpenOffice (and presumably, StarOffice) documents. Their MIME-type is already set to text-plain, allowing them to be covered by one of the default rules.

How beneficial is sending GZIP-encoded content? In some simple tests I ran on my Web server using WGET, GZIP-encoded documents showed that even on a small Web server, there is the potential to produce a substantial savings in bandwidth usage.

http://www.pierzchala.com/bio.html Uncompressed File Size: 3122 bytes
http://www.pierzchala.com/bio.html Compressed File Size: 1578 bytes
http://www.pierzchala.com/compress/homepage2.html Uncompressed File Size: 56279 bytes
http://www.pierzchala.com/compress/homepage2.html Compressed File Size: 16286 bytes

Server administrators may be concerned that mod_gzip will place a heavy burden on their systems as files are compressed on the fly. I argue against that, pointing out that this does not seem to concern the administrators of Slashdot, one of the busiest Web servers on the Internet, who use mod_gzip in their very high-traffic environment.

The mod_gzip project page for Apache 1.3.x is located at SourceForge. The Apache 2.0.x version is available from here.


[1] From http://www.15seconds.com/issue/020314.htm

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

MSIE 7.0

February 15th, 2005 by smp | Comments | Filed in RANTING

That is not a typo. The great man spoke the words today. [here and MSFT Press Release and here and here and here and here
and here and here]

Will it be better…?


The quote:

Building on those advancements, Gates announced Internet Explorer 7.0, designed to add new levels of security to Windows XP SP2 while maintaining the level of extensibility and compatibility that customers have come to expect. Internet Explorer 7.0 will also provide even stronger defenses against phishing, malicious software and spyware. The beta release is scheduled to be available this summer.

But what will those features be?

  • Complete CSS2 support? Hell! CSS1?
  • Full HTTP/1.1 compatability?
  • Final removal of ActiveX?
  • Truly enforce [X]HTML standards for publishing?
  • Simple extensibility for any developer?
  • Themes/Chrome?
  • A matching version for MacOSX?

They know they are in trouble. They are generating buzz. But if they have just patched and incremented MSIE 6.0, without re-engineering the core parser, rendering and networking engines, then it won’t be worth talking about.

Come on Microsoft: Impress me.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , ,