Apache logs contains “\x16\x03\x01” when accessing site via HTTPS

Today setting up SSL for a Apache HTTP webserver I run into issue, when browser shows that site is not accessible. At first I thought that SSL (443) port is not open, but looking in the Apache log file I saw this: - - [24/May/2010:12:01:45 +0300] "\x16\x03\x01" 200 12332 "-" "-"

The place where GET request should be was “\x16\x03\x01”. Like some encoding problem I thought. The bonus to all this, was that I have test environment with the same settings, and everything worked under test server.

The problem was: I forgot to change IP address in Apache conf file that was left from test server configuration. Of course, Apache does not respond to address it does not have.

So if you get “\x16\x03\x01” in Apache log file, then you may have not configured Apache for HTTPS / SSL on that IP address.

How big HTML images / CSS / JS / png / etc. should be to fit network packet (MTU) efficiently

List of little things that will make your website much faster.

Not every webmaster knows, that 1 extra byte in jpg image, can cause 100% speed reduction / penalty for your website visitor. When you learn that MTU for Ethernet is 1500 bytes with actual data / payload size of 1460 bytes, you can calculate optimal image / resource sizes.

First network packet gets penalty because it includes HTTP server response. Typical HTTP 1.1 response is from 284 for PNG up to 363 for JS, but usually is bigger if not optimized. You can remove most of stuff in this response, but you will get another penalty in form of missed caches that leads to slower website loading speed for user with repeat views (returning visitors).

Here is an example of good optimized HTTP response header for PNG image:
HTTP/1.1 200 OK
Date: Tue, 19 May 2010 14:07:55 GMT
Server: Apache
Last-Modified: Wed, 05 May 2010 14:43:16 GMT
Content-Length: 2502
Cache-Control: public
Expires: Thu, 18 Jun 2010 14:07:55 GMT
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: image/png
...data goes here...

If you like to mess with Apache you can remove Server header, but there is a known bug, that makes this removing non-trivial.

Making response as small as possible, makes room for more actual payload (be it – jpg, png, css, js) in first network packet. So, optimally image / script / stylesheet file size needs to occupy at most bytes of used packets. For example, if your image is 1300 bytes, then payload size is 1300 + 284 HTTP response, thus first packet payload is full 1460 bytes and second packet is used inefficiently – only 124 bytes. As we know, we send packets not bytes or bits. There is little to no difference in sending one byte or 1460 bytes. In this example, the suggestion is to reduce image size by 124+ bytes, thus causing image to fit into one packet. Or use 1336 bytes to increase image quality, thus causing image to fit in the same 2 packets, but with two times better image quality. (Anyway, these 1336 bytes is almost always unused / wasted)

Now if you know your header sizes and you optimize your site for best user experience / speed, it is wise to use all space provided by packets.

It is easy to create Spreadsheet with recommended payload sizes for all resources using the following formula:
1460 * network packets - HTTP response = maximum resource size

Remember, that every resource (png, jpg, gif, js, css, etc.) will have different HTTP response header size.

Here is a snippet from table I use daily for one of my websites that needs to be optimized for fastest page loading speed:
Optimize payload size for png

If you exceed resource by one byte, you immediately get one extra packet, that can cause speed reduction by 100%.

Now if you now this, you can go and examine www.google.com or www.yahoo.com root pages. You will find that all images are optimally fitted in optimized packet count / sizes. For example google.com png response size is 278 bytes, image is 6803 bytes. So Google is using approximately 1200 bytes of last packet. It is not coincidence, it is designed with page loading speed / quality in mind.

Also, remember that this is only small step in web site speed optimization. Here are some other tips from my checklist that can cause significant increase of page load times / user experience.

List of little things that will make your website much faster:

  • Server must support Keep-Alive. Otherwise change server / host / hosting company / etc. Do it NOW!
  • Reduce HTTP requests (CSS sprites, combine CSS, combine JS, inline CSS, inline JS)
  • Minifiy HTML, JS, CSS. Google Closure Tools, YUI Compressor, Minification
  • Gzip text/html, css, js (IE6 does not un-gzip CSS and JS, if reference is not from HEAD)
  • For IE 5 & 6 use gzip-only-text/html
  • Check if (Content-Encoding: gzip) then (Vary: Accept-Encoding) to allow cache both versions in proxy servers
  • CSS goes in head, JS goes at bottom – right before body closing tag
  • Defer JS if possible. Defer allows to load js after onload
  • Compress images (for photo like always jpg, for everything else PNG 8, for anim GIF)
  • Think connections! Waterfall. webpagetest.org (probably the best site for web page speed / optimization test), Zoompf (a little overkill, but can be useful), Pingdom Tools
  • Try to serve assets in parallel, e.g, images.example.com, images2.example.com; subdomains can be on the same IP
  • Use 2-3 max 4 sub-domains
  • Optimize response headers, smaller, meaningful
  • Remove ETAG
  • Use Expires + cache-control
  • 25k and greater files are not cached on iPhone
  • Cache dynamic content PHP, ASPX, ruby etc.
  • example.com?param is not cached by most proxies
  • Serve static assets from cookie-less domain, like yimg.yahoo.com
  • After onload via js can pre-cache images (if you know where visitor will go next)
  • Can use double heads (if a lot of meta then put 2nd head at the bottom after closing BODY tag)
  • Use CDN if can afford

And remember about:

P.S. To cover each optimization topic in details, I can write a whole book. I am not going to do this yet, so if you have any questions, ask in comments!

Author Ha.

Updated 22 Jun 2010.