Tools and utilities developed by Nir Sofer

Last update : March 2, 2013

NirSoft USDDeview Tool

I recently discovered the unique collection of small and useful freeware utilities and tools, available on the website NirSoft, created in 2001. The name NirSoft is the combination of the developers first name Nir and the prefix of the word Software, respectively the last name of the developer, Sofer.

Nir Sofer is an experienced developer with extensive knowledge in C++, .NET Framework, Windows API, and Reverse Engineering of undocumented binary formats and encryption algorithms.

The domains covered by the more than 100 tools of NirSoft are various : Password Recovery, Network Monitoring, Web Browser, Video/Audio, Internet, Desktop, Outlook/Office, Programming, Disk, System, …

All of the utilities are fast, small, portable and effective. Most are developed in C++ and don’t require any installation.

My favorite Nirsoft tools are the following :

Nir Sofer provides also tips and tricks about computers and software as well as code samples.

Fiddler : Web Debugging Proxy

Last update : May 22, 2015

Building web applications is hard work and most people remain unaware of how their web application is interacting with the web browsers that their clients have installed. Fiddler,  a free web debugging proxy created by Eric Lawrence, helps to simplify the analysis process substantially by logging all HTTP(S) traffic between your computer and the Internet. Fiddler is a transparent proxy that automatically adds itself to the WININET chain so that it can see every request being made. It logs those requests and the responses to allow you to see what is working and what isn’t working.

Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and “fiddle” with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language. Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more.

The developper, Eric Lawrence, was Security Program Manager at Microsoft for Internet Explorer. After over a decade of working on the web for Microsoft, Eric joined Telerik in October 2012 to enhance the Fiddler Web Debugger on a full-time basis. Telerik is devoted to making software development easier and more fun and has committed to keeping Fiddler free and expanding its value by further investing into the tool.

A quick summary of getting started with Fiddler has been published at Developer.com. A detailed documentation is available at the Fiddler website. A discussion forum and a developer section are available at the same site. Various addons and third-party extensions have been developped.

Fiddler can be configured to analyse the http traffic of iPad’s, iPhone’s and other web devices.

A simular tool called Charles is available for Mac Computers.

Some related tutorials about Fiddler and HTTP debugging are listed hereafter :

Time to Live (TTL) of objects on Amazon Cloudfront

Time to live (TTL) is mechanism that limits the lifespan of data in a computer or network. In HTTP, TTL is expressed in the response header as a date and time on which a record expires.

On Amazon Cloudfront, the default TTL is 24 hours. In April 2010, Amazon Cloudfront announced that it will honor shorter TTL’s down to one hour. The HTTP header can be set in the Amazon AWS Management Console.

To refresh a specific file on Amazon Cloudfront, you can use the Invalidation API. The Bucket Explorer has a UI that makes Invalidation pretty easy. Informations about an Amazon CloudFront – PHP Invalidator are availble at the subchild website.

Manipulating HTTP Headers with .htaccess

Last update : July 25, 2013

.htaccess is a very ancient configuration file that controls the Web Server running your website, and is a very powerful configuration file. htaccess is sometimes called “HyperText Access” because of its ability to control access of the WWW’s HyperText Transfer Protocol (HTTP) using Password Protection, 301 Redirects, and much much more.

The AskApache website offers a lot of tutorials, tricks and hacks for webmaster and online tools related to .htaccess.

.htaccess tips and tricks are available at the corz.org website.

Progressive video download, pseudo streaming and realtime streaming

Last update : January 30, 2013
In the past, audio and video on the Web was primarily a download-and-play technology. You had to first download an entire media file before it could play. Today, streaming technologies allow watching audio and video files almost immediately, while the data is being sent, without having to wait for the whole file to download.

There are three methods of delivering streaming audio and video content over the Web.

The first method uses a standard HTTP server to deliver the audio and video data to a media player. Unlike the download-and-play client, a special streaming client embedded in the webpage starts playing the audio or video while it is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. This streaming method is called progressive media download.

The second method is called pseudostreaming. Pseudostreaming is a protocol that can be installed on regular HTTP servers. It uses a server side script for Flash-to-server communication. The player sends a HTTP request to the server with a start time parameter in the request URL’s query string and the server script responds with the video stream so that its start position corresponds to the requested parameter. This start time parameter is usually named simply start. The video viewer skips the nondownloaded parts of the videos.

Both FLV and MP4 video can be played back with  pseudostreaming. The following scripts or tools are available :

  • The H264 streaming module for Apache, Lighttpd, IIS and NginX.
  • The mod_flv_streaming module for Lighttpd.
  • PHP/ASP scripts such as XmooV PHP.
  • Content delivery networks such as Bitgravity, Edgecast or Limelight.

There is one major advantage to streaming with a Web server rather than with a streaming media server—utilizing existing infrastructure.

The third method uses a separate streaming media server specialized to the audio/video streaming task. A streaming server offers the following advantages :

  • More efficient use of the network bandwidth
  • Better audio and video quality to the user
  • Advanced features like detailed reporting and multi-stream multimedia content
  • Supports large number of users
  • Multiple delivery options
  • Content copyright protection

The following protocols are commonly used by streaming servers :

  • UDP – this protocol provides the most efficient network throughput. The only downside to UDP is that many network administrators close their firewalls to UDP traffic, limiting the potential audience of UDP-based streams
  • TCP – this protocol provides an adequate, though not necessarily efficient, protocol for delivering streaming media content to flow through the firewalls
  • HTTP + TCP – this combination has the benefit of working with all firewalls that let Web traffic through (port 80) and provides much more control (fast forward, rewind, etc) than a standard Web server, but also adds some overhead to the raw TCP stream that decreases scalability.
  • Multicast – this protocol enables hundreds or thousands of users to play a single stream, but will only work on networks with Multicast-enabled routers. Multicast is becoming prevalent on corporate networks, but is still very rare on the Internet

Useful informations and tutorials about streaming are available at the streamingmedia.com website.

In 2009, Amazon CloudFront, the easy-to-use content delivery service, introduced the ability to stream audio and video files. Streaming with Amazon CloudFront is exceptionally easy: with only a few clicks on the AWS Management Console or a simple API call, you’ll be able to stream your content using a world-wide network of edge locations running Adobe’s Flash® Media Server. Like all AWS services, Amazon CloudFront streaming requires no up-front commitments or long-term contracts. There are no additional charges for streaming with Amazon CloudFront; you simply pay normal rates for the data that you transfer using the service.

Web-Sniffer : View HTTP Requests and Responses

Last update : October 21, 2016

HTTP Response Headers are just lines of text sent from the server to the browser before the page content. They are terminated with a blank line, after which the page content is deemed to begin. HTTP Requests are lines of text sent from the browser  to the server.

A very useful tool to check HTTP Request and Response Headers is available at the web-sniffer.net website.

A typical output of a HTTP Request Header by the web-sniffer is shown below :

HTTP Request Header

Connect to 80.90.45.105 on port 80 ... ok

GET / HTTP/1.1[CRLF]
Host: www.saraproft.net[CRLF]
Connection: close[CRLF]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; 
rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 GTB7.1 
( .NET CLR 3.5.30729; .NET4.0C)[CRLF]
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[CRLF]
Cache-Control: no[CRLF]
Accept-Language: de,en;q=0.7,en-us;q=0.3[CRLF]
Referer: http://web-sniffer.net/[CRLF]
[CRLF]

HTTP Headers are strings terminated by a CR (carriage return) and LF (Line feed) character (‘rn’ string). The order of header lines withing the HTTP header has no significance. Any header fields which are not understood should be ignored. A CRLF string after the last header is followed by the content part of the webpage.

Web-Sniffer is also available as free desktop app for Windows and Mac (version 1.0.0 Beta, Build 26, released on June 23, 2013).

Web-Sniffer App on Mac OS X El Capitan

Web-Sniffer App on Mac OS X El Capitan