28 July 2011

Exchange 2010 publishing with TMG troubleshooting tool

#TMG - #Exchange

Troubleshooting a TMG published Exchange 2010 environment can be a tricky task especially if you are trying to get multiple devices to sync up.  Fortunately there is help.  The Microsoft Remote Connectivity Analyzer.

https://www.testexchangeconnectivity.com/  This site enables you to test the various connectivity scenarios that may be encountered.

The testing procedure is quite simple.

Step 1 Browse to the Site
https://www.testexchangeconnectivity.com/
Select the test you want to perform.  This can be one of:


Microsoft Exchange ActiveSync Connectivity Tests 

  • Exchange ActiveSync 
  • Exchange ActiveSync Autodiscover  

Microsoft Exchange Web Services Connectivity Tests 

  • Synchronization, Notification, Availability, and Automatic Replies (OOF) 
  • Service Account Access (Developers)  

Microsoft Office Outlook Connectivity Tests 

  • Outlook Anywhere (RPC over HTTP) 
  • Outlook Autodiscover  

Internet E-Mail Tests 

  • Inbound SMTP E-Mail 
  • Outbound SMTP E-Mail  





Step 2 Provide the relevant test criteria

Note the following :  I understand that I must use the credentials of a working account from my Exchange domain to be able to test connectivity to it remotely. I also acknowledge that I am responsible for the management and security of this account.

You are providing the test credentials for an active account.  Use a test account or change the password after completing the test.


Step 3 Evaluate the Results

It is actually surprising to see how many steps there are in the process.  It will let you know where things succeed and where they fail.  The further information link supplied also returned very relevant useful information to resolve the issue highlighted.



If you get the clean bill of health form the test you know that your TMG and Exchange infrastructure is functioning correctly and you can thus focus on the other problem areas.

27 July 2011

RDS Limit application execution to privileged users only

#WindowsServer

RDS by default has your remote users logged on as a member of the Users local group.  This can present a potential issue in that these users can execute application to which you may not want them to have access.

The whole point behind publishing an application and limiting it to a particular group of users is because that is where you want to set the limit.  If a user has access to a shell then they can execute any application for which they have execute permission.

In http://fixmyitsystem.com/2011/07/limit-rdp-inbound-and-outbound-access.html I show how to limit the access for RDP connectivity.  The following steps will actually prevent a normal user from being able to execute the mstsc RDP client.  It will however work for any executable.

Take Ownership
Files often are owned by SYSTEM or Trusted Installer.  As a result even and administrator can not set permissions on these files.  You can however claim ownership and then you can set permissions.

  • Browse to C:\Windows\System32\
  • Select and right click mstsc.exe
  • Click Properties
  • Select the Security Tab
  • Click the Advanced Button
  • Click the Owner Tab
  • Click the Edit Button
  • Select a user or group you want to assign ownership

Set Execute Permission
File level NTFS permission control what actions a user can perform on the file. The following will restrict normal users from executing the mstsc executable.

  • Browse to C:\Windows\System32\
  • Select and right click mstsc.exe
  • Click Properties
  • Select the Security Tab
  • Click Edit
  • Select the Users group
  • From the Permissions window un-check Read & execute
  • Click add and select the group you want to allow execution
  • Ensure that the Read & execute is checked
  • OK
  • OK


Conclusion
RDS presents some unique challenges. It can be an extremely usefull tool but it can also present a big security risk.  Applying some "what would a malicious user do" though can help you eliminate existing and potential problems.

22 July 2011

RDS Certificate usage and renewal steps

Remote Desktop Services relies heavily on certificates.  As a result I recommend install the certs on all the servers before you even start, this allows you to select the cert without having to remember to go back and fix it later.  Certificate expire though and as such you need to renew them or replace them periodically.

If your certificates are not correctly installed or assigned you might have issue with access and single sign on SSO.  I have run into so many issues regarding certs I have actually given up keeping track.

These are the steps to successfully implement a certificate swap or update.

The Environement
1 x Server configured as RDWEB, RDCB, RDGW - (RDS01)
2 x RDSH servers in NLB for most applications - (RDS02 & RDS03 NLB name RDS)
1 x RDSH server for non NLB applications - (RDS04)

What certificate to use
You need to use a multi-domain certificate or SAN certificate.  The names vary form CA to CA but it is a single certificate that is valid for multiple names.  This enables all the different rules to use a single certificate and this has proven to be the best way to proceed.

You need to register you Multi-domain certificate with at least the following names


  • RDWEB
  • RDGW
  • RDS
  • RDS04


Where to install the certificates
Since you are using a multi-domain certificate you install the same certificate on all the RDS servers.  In addition if you are publishing your RDS environement to the Internet through TMG (Forefront Threat Management Gateway) you need to install it on all the array members.  You then need to assign the certificate to the RDS publishing Listener network object.

For steps export and import the certificate on the servers check http://fixmyitsystem.com/2011/02/exporting-and-importing-ssl-certificate.html

Assigning the certificate to the various roles
Now that the certificates are on all the servers you need to use them.  The various roles and componenets need to be configured correctly.

RD Gateway 

  • From the RD Gateway Manager console
  • Highlight the RDGW server name 
  • Click properties from the actions pane
  • Select the SSL Certificates tab
  • Select the option "Select an existing certificate..."
  • Click Import Certificate
  • Select the certificate
  • Click import
  • You will be prompted to restart the RDGW service


RD Web

  • From the IIS manager console
  • Select Default Web Site
  • Click Binding from the Actions pane
  • Select HTTPS
  • Click Edit
  • From the SSL certificate drop down select the certificate

RD Connection Broker

  • From the Remote Desktop Connection Manager
  • In the status pane under Virtual desktop : Resources and Configuration
  • On the line Digital certificate click Specify
  • On the Digital Signature tab
  • Check Sign with Digital Certificate
  • Click the Select Button
  • Click on the certificate to use
RD Session Hosts PART I
The following needs to be done on every session host
  • From the MMC console
  • Add the certificates snap in
  • Select Computer account
  • Expand Personal - Certificates
  • Open the RDS SAN certificate
  • From the details tab select the Thumbprint field
  • Copy and paste the value into notepad
  • Delete all the spaces
  • You should now have a string 40 characters long
  • Copy the following script and save it as RDconfig.js
var strComputer = ".";
var strNamespace = "\\root\\CIMV2\\TerminalServices";
var wbemChangeFlagUpdateOnly = 1;
var wbemAuthenticationLevelPktPrivacy = 6;
var Locator = new ActiveXObject("WbemScripting.SWbemLocator");
Locator.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy;
var Service = Locator.ConnectServer (strComputer, strNamespace);
var TSSettings = Service.Get("Win32_TSGeneralSetting.TerminalName=\"RDP-Tcp\"");
if (WScript.Arguments.length >= 1 )
{
    TSSettings.SSLCertificateSHA1Hash = WScript.Arguments(0);
}
else
{
     TSSettings.SSLCertificateSHA1Hash = "0000000000000000000000000000000000000000";
}
TSSettings.Put_(wbemChangeFlagUpdateOnly);
  • On the RDSH server open a command prompt as administrator
  • Execute the script with the 40 character thumbprint string as the parameter
For more details on this step check 


RD Session Hosts PART II
The following needs to be applied to all the RDSH servers.  This can be done directly on each or exported via the console.

  • From RemoteApp Manager Console
  • Next to Digital Signature Setting click Change
  • Check Sign with digital certificate
  • Click the Change button
  • Select the correct certificate

  • Click Export RemoteApp setting 
  • Select Export the RemoteApp... to another RD Session Host server
  • Specify the name of the other RDSH server
  • Repeat for all the hosts in the RDCB farm

Updating TMG
If you are publishing to the outside world through TMG you will need to update the listener being used with the new certificate.

  • From the TMG management Console
  • Expand to the Firewall Policy
  • Open the rule used for publishing RDS
  • From the Listener tab click Properties
  • From the certificates tab click select certificate
  • Choose the new certificate

Conclusion
Configuring or updating an expired certificate for RDS can be a tricky exerciser especially if you miss a certificate setting.  Troubleshooting can also be frustratingly difficult.  Plan your environement with grwoth in mind.  This should then allow you to request certificates with additional SANs should you need them.  I would also recommend getting them with a 2 year validity, this in itself will save you some cash and effort. 

12 July 2011

Limit RDP inbound and outbound access to specific IPs

RDP access in and out of a machine can be a very useful tool.  It can however also present a big security headache. A user that is a member of the Remote Desktop Users group you can log onto the server.  By default there is no granular way to restrict where the connection come from.  As an example, you may only want to allow certain management stations to RDP to your servers.  To achieve this restriction you can make use of the Windows Firewall.

The Default Inbound Rules
There are some default rules for RDP access.  These are activated when you enable remote desktop access

Remote Desktop (TCP-In)
Remote Desktop - Remote FX (TCP-In)

These rules when enable will allow connection from anywhere and is applied to all the network profiles.

Editing the Allow Rule
Once active you can edit the Remote Desktop (TCP-In)

From the Windows Firewall advance console do the following:

  • Select Inbound Rules
  • Right click and select properties for the Remote Desktop (TCP-In) rule
  • Select the Scope tab
  • In the remote IP address section select "These IP addresses"
  • Click Add
  • Add the IP or range of IPs that you want to grant access from.

(In our example these would be the management consoles)

Creating a Deny rule.
This is the most suitable approach if you gennerally want to allow all ips acess except a few ranges
Create a restrictive inbound rule do the following from the Windows Firewall advance console:


  • Select Inbound Rules
  • Click New Rule form the actions pane
  • Select Port
  • Select TCP
  • Specify port 3389
  • Select Block the connection
  • Select all three network profiles
  • Specify a Rule name and description (Remote Desktop Granular Deny)
  • After creation open the rule for editing
  • Select the Scope tab
  • In the remote IP address section select "These IP addresses"
  • Click the add button
  • Enter either the IP subnet or range that you want to block.
  • You can add multiple IPs or IP ranges 

For this to work the default allow rule must be enabled.

Outbound Rule
If you want to restrict the RDP machines that the client can connect to you will need to specify an outbound deny rule.

Do the following from the Windows Firewall advance console:


  • Select Outbound Rules
  • Click New Rule form the actions pane
  • Select Port
  • Select TCP
  • Specify port 3389
  • Select Block the connection
  • Select all three network profiles
  • Specify a Rule name and description (Remote Desktop Granular Deny)
  • After creation open the rule for editing
  • Select the Scope tab
  • In the remote IP address section select "These IP addresses"
  • Click the add button
  • Enter either the IP subnet or range that you want to block.
  • You can add multiple IPs or IP ranges 
It is important to note that you have explicitly specify the addresses that you want to deny access.

You can also restrict certain users from even executing the RDP client in an RDS environment
http://fixmyitsystem.com/2011/07/rds-limit-application-execution-to.html

Incorrect Icons showing in Remote Desktop Services Web Access

In the RDS web access screen you may sometimes come across broken or wrong icons for the published applications.



I have found two possible reasons for this.

The application is no longer available on the RDS host.  In this case you can see the application as being crossed out in the RemoteApp manager.



The other occurred when I removed some applications.  All the application switched to the default icon.  When I looked at the RemoteApp manager all the applications were listed correctly with the correct Icons.  If I specified a windows Shell icon then it would update the icon.  If however I specified an application icon it would not update.  To resolve this you need to either remove and re add the application or change the application alias.  After this the icons will show up correctly again.


11 July 2011

Caching in IIS, TMG and the browser - How it all fits together Part III - IIS cache

In the previous two parts of this article

Caching in IIS, TMG and the browser - How it all fits together Part I - Browser cache

We explored how the items being served from a web server gets stored and retrieved further down the line.  Other than defining what items are allowed to be cached and which items are not, IIS also performs its own output caching.

Configuring Output Caching in IIS

There are many resources explaining how to configure caching in IIS.  I will focus just on the very basics and how it interacts or interferes with the the other caches.

There are a few basic concepts you need to be aware of for the next section to make sense.

  • Output Caching settings
  • Feature Settings
  • Enable User made Cache
  • Enable Kernel cache
  • Maximum cached response size
  • Cache Size Limit
  • Cache Rules
For the detailed information on these check http://technet.microsoft.com/en-us/library/cc732475(WS.10).aspx

The resultant cache configuration will be visible if you examine the HTTP header information on your test machine.


In essence, if caching is setup correctly at the web server level all other caches should "fall in line" by perpetuating the cache setting you specify at the web server.  If however the cache configuration on the web server is bad - you will propagate those wrong settings all the way down to the browser cache.

Configure a test machine
By design, a machine will use all the caches in sequence, and hide the details from you.  To troubleshoot the IIS cache you need to setup a test machine to eliminate all other caches.  

Proxies
This entails having to bypass using either a forward or reverse proxy cache by checking your browser connection settings.  Te ensure a forward cache is avoided set your browse to use "no proxy."    To test your application connect to the host server's name directly and not through a reverse proxies name or IP.  If you are connecting to an NLB web application try hit only one of the servers by using a unique non NLB IP.

Disable Browser cache
Firefox and Firebug has a very useful feature for this.  It allows you to totally disable the browser cache.  From the Net tab check the "Disable Browse Cache."  All requests to the same content should now generate a 200 response code, because all items are being retrieved remotely.   



This should now have set up a reliable machine to test your IIS cache.

Checking on caching performance

As with Browser and Proxy cache, the caching is something that is transparent by design, as in there is no way for you to know where the data is coming from unless you are looking at the correct layer.

For IIS you use Performance Monitor.  Add the Web Service Cache counters

There are various section of counters, that give you information from the different cache components. 

Probably most important is the section in orange here.  The "Current" counters give you information about the existing state
  • File Cache Memory Usage
  • Files Cached
  • Metadata cached
  • URIs Cached
The cache is generally dynamic and as such these numbers should change.

By generating repeat requests from your test machine you should see the files being loaded into cache and then getting cache hits thereafter.  Once the TTL for the cache file expires it should automatically be flushed.

This is going to be specific to the output cache sestting for that site / application, So you need to know what you want to test for.  (In my test example I want to ensure the .jpg files are not cached at all)


Clearing the cache manually
If items were incorrectly marked for caching they could be stuck in the server output cache for a long, long time.  You would then want to clear the cache so that all browser and proxy connection can determine that the item had changed and therefor flush the down level caches.

Before starting to flush the cache  have a look at the current counters.


To totally clear to cache do the following:

From the IIS management console
  • Disable output caching at the IIS server level.
  • Restart IIS
  • Re-enable output caching
  • Restart IIS
Once this is done you check the "current counters" again.  All the current values should be 0.  Your cache items should come in when being called for and should get flushed as the desired TTL is reached.  Use your test machine to verify this behavior.


Conclusion
Caching is a great way to improve web performance and it does this by take load of the client machines the common networks and the web servers.  If however you get something stuck in cache it could be difficult to find out where it is getting stuck and then to flush it.

Default caching setting on browse and TMG and even IIS may not leverage every single grain of performance gain, but they do "line up" nicely.  Uninformed fiddling with these, could introduce cache related issues without realizing any significant gain.






06 July 2011

Caching in IIS, TMG and the browser - How it all fits together Part II - TMG proxy cache

In Part I - Browse Cache I explored how the local browser reduces the amount of internet calls and downloaded data by caching valid content.

Proxy Cache
The second part to this is the proxy server.  Most common is a client side proxy that allows them to browse the internet.  This keeps a cache that is used to fill all subsequent requests to the same content.  One significant difference from browser cache is that this is a common cache that can be called on by all users of the proxy. This is called forward caching

This same principal is used for reverse proxy.  Web application published to the internet can take advantage of the proxy cache to reduce calls to the web servers for cache-able content.  This is reverse caching.

Browser and proxy cache is cumulative in that the browser will only retrieve content it needs that it can not  fill from local cache, if the content is in the proxy cache it will be returned from there.

Content Retrieval
When looking at the TMG logs you can easily see where content is served from by adding the Object Souce column.  The object source could be once of the following:


  • Internet - Returned from the internet, and object is added to cache
  • Cache - Object is returned from cache
  • Not Modified - Returned form cache. An If-Modified-Since request found that the object had not been modified
  • Verified Cache - Returned form cache - Object verified to the source as not modified
  • Verified Failed Internet - Returned form the Internet - Very form source indicated a change
  • Not Verified Cache - Returned form cache - Object could not be verified
  • Upstream - Returned form Upstream proxy cache - web chaining



Something to note is that when the source is Internet the request goes out to the public network.  If it is Not Modified Cache etc, it only goes to the TMG cache.

Cache Control
Content retrieval is based on the cache control information in the HTTP header.  Since there are various web servers that differ in their header generation there are a number of possible cache information values.

TMG assigns a caching information code based on the headers.

  • 0x00000001  - Request should not be served from the cache. 
  • 0x00000002  - Request includes the IF-MODIFIED-SINCE header. 
  • 0x00000004  - Request includes one of these headers: CACHE-CONTROL:NO-CACHE or PRAGMA:NO-CACHE. 
  • 0x00000008  - Request includes the AUTHORIZATION header. 
  • 0x00000010  - Request includes the VIA header. 
  • 0x00000020  - Request includes the IF-MATCH header. 
  • 0x00000040  - Request includes the RANGE header. 
  • 0x00000080  - Request includes the CACHE-CONTROL: NO-STORE header. 
  • 0x00000100  - Request includes the CACHE-CONTROL: MAX-AGE, or CACHE-CONTROL: MAX-STALE, or CACHE-CONTROL: MIN-FRESH header. 
  • 0x00000200  - Cache could not be updated. 
  • 0x00000400 IF-MODIFIED-SINCE time specified in the request is newer than cached LASTMODIFIED time. 
  • 0x00000800  - Request includes the CACHE-CONTROL: ONLY-IF-CACHED header. 
  • 0x00001000  - Request includes the IF-NONE-MATCH header. 
  • 0x00002000  - Request includes the IF-UNMODIFIED-SINCE header. 
  • 0x00004000  - Request includes the IF-RANGE header. 0x00008000 More than one VARY header. 0x00010000  - Response includes the CACHE-CONTROL: PUBLIC header. 
  • 0x00020000  - Response includes the CACHE-CONTROL: PRIVATE header. 
  • 0x00040000  - Response includes the CACHE-CONTROL: NO-CACHE or PRAGMA: NO-CACHE header. 
  • 0x00080000  - Response includes the CACHE-CONTROL: NO-STORE header. 
  • 0x00100000  - Response includes either the CACHE-CONTROL: MUST-REVALIDATE or CACHE-CONTROL: PROXY-REVALIDATE header. 
  • 0x00200000  - Response includes the CACHE-CONTROL: MAX-AGE or S-MAXAGE header. 0x00400000  - Response includes the VARY header. 
  • 0x00800000  - Response includes the LAST-MODIFIED header. 
  • 0x01000000  - Response includes the EXPIRES header. 
  • 0x02000000  - Response includes the SET-COOKIE header. 
  • 0x04000000  - Response includes the WWW-AUTHENTICATE header. 
  • 0x08000000  - Response includes the VIA header. 
  • 0x10000000  - Response includes the AGE header. 
  • 0x20000000  - Response includes the TRANSFER-ENCODING header. 
  • 0x40000000  - Response should not be cached.

Configuring Proxy Cache
When enabling Web Caching from the web access policy, you can specify the following. But first consider the following.

  • The cache on TMG is stored in both memory and disk.  
  • By default 10% of the ram is reserved for cache.  
  • Cache drives should then at least exceed the 10% of RAM size.  
  • The maximum cache file size is 64GB per drive.  
  • Files bigger than 512MB are not retained in cache after a reboot.
  • CARP
  • Cache Rules and exclusions

TMG arrays make user of Caching Array Routing Protocol (CARP)  it essentially reduces overhead  by serving the content out of the array member that already contains the cached item.  If the client is using a proxy configuration script (wpad) then client side CARP is used, this eliminates the need for array members to forward requests between each other, this reduces overhead. If they are not using a configuration script the CARP is performed by the Array members and web chained proxies.

General tab
You only Enable or Disable the rule

Cache Drives
You need to specify the drive and amount of space that you want to allocate to cache.  Rember that this should at the very least be bigger than 10% of the TMG server's RAM.  This setting needs to be specified per array member.  The default location of this files is C:\urlcache\dir1.cdat

Cache Rules
You should have three rules by default.

  • Microsoft Update Cache Rule - This is an exclusion rule
  • Web access scenario cache rule - This is an inclusion rules
  • Default Rule
To tab
This at first glance is a little misleading since here you need to specify "Cache content requested from these destinations"  You can also specify exceptions.

The Cache Store and retrieval tab 
This allows you to specify the behavior of the cache. 


Currently the default settings are indicated.  If you wish to store additional items in cache - I woulds suggest setting up a specific cache rule for that URL set / network.  Move this rule up above the "Web access scenario cache rule."

Content download tab
From here you can create jobs to run on a schedule to pre-download items and store it cache.  You can specify the download to exclude external links and the maximum depth of links to follow per page.  When specifying content caching you need to define how you want to cache that pre-downloaded data.  You have the ability to overwrite the caching information you receive from the web server and replace it with your own.  Bearing in mind that your setting will filter down to the browser cache and affect how it stores cache.


On a personal note.  I have never needed to implement this.  If it is a frequently visited site by your proxy users, most of it will already be cached.  But it is there should you need it.

Advanced tab 
You get to set cache setting for content that have not got explicit cache setting.  You can cache object that have not got a successful download return code (200)
You can also configure additional setting for content that was marked to expire.

Also - quite important, but hiding away in the bottom of the last page is the setting for how much RAM to commit to caching.


Inspecting, refreshing and clearing the cache
Occasionally you might have to clear the cache.  If for instance a specific site had incorrectly specified content to be cached, TMG would normally use the same caching parameters.  You could then for instance have a object that is supposed to be dynamic "stuck in cache" with no way for the users to refresh it.

The crude but very effective way of fixing this issue is to clear the cache by deleting the cache files.   To do this you need to remove the cache drive from the array members, the services would then need to restart, Manually delete the cache files on all the array members.  Then you can add the cache drives back in again.  You will however lose every single cached item.  So users would have to start building it up from scratch.

If however you want to expire only a specific item you can use the Cache Directory Tool. http://www.microsoft.com/download/en/details.aspx?id=11183

To avoid the "The program can't start because msfpc.dll is missing on your computer." You need to copy the cachedir.exe into the TMG installation directory.

When you launch the tool give it a minute to go through the cache file.  Once loaded you can see all the items and the following details.
  • Page name - object name
  • Server - URL
  • Content size
  • Content MIME type
  • Expires 
  • Last Modified
  • Age
  • Protocol
  • Port #
  • Encoding
You can clear an item out of  the cache file by marking it as obsolete.


One important thing to keep in mind though. This will only clear it out of cache for that array member.  It will also only delete it form the file system and not from RAM.

Conclusion
TMG provides a flexible caching solution.  The default setting work just fine for most applications as it does not attempt to overwrite the caching information received fomr the originating web server.  You can force items to be cached but it is a cumbersome task to get them out again should there be a problem.

For reverse caching you can offload some of the cache functionality from the web servers, the effectiveness and saving because of this is largely determined by the application.  If an item that would normally be static with a long TTL like say a style sheet gets changed that change would only become visible to the user if the web server, proxy and browser cache has expired.

04 July 2011

Caching in IIS, TMG and the browser - How it all fits together Part I - Browser cache

Caching as a mechanism for speeding things up has been around for a long time now.  It is unfortunately a concept that is not well understood.  The reason for this is probably because there are so many variables.

In this series of articles I will cover the fundamentals of caching at the three main locations.  Web Server, Proxy cache (TMG) and the local browser cache.

Client Browser Cache

When items are flagged as being valid for caching the items are stored locally on the client machine.  When the items are requested again, the items are retrieved from the local file system.

This has the advantage of reducing the TCP round trip as well as reducing the amount of data that needs to be downloaded.

When using an HTTP sniffer such as HTTP Watch or Fire Bug you can observer the result codes.  To find out more about the result codes check http://fixmyitsystem.com/2011/07/http-status-codes-quick-guide.html


First Visit
At first visit to a page you will return result 200 for all the items.  This indicates that the item was successfully downloaded.  Looking at the other column values you can see that the sent and receive indicate the size of them items


Cache allowed items will now be written into the local machine cache.  The setting for this is specified in the Internet Explorer  - Internet Options - Browsing History - Settings.  There are 4 options for updating the cache, they are:

  • Every time I visit the webpage
  • Every time I start Internet Explorer
  • Automatically (default)
  • Never


You can also specify the amount of disk space you want to allocate as well as the cache location.  It is important to note that this is a user specific cache. As in, even if another user logs onto the same machine the cache would not be available to them.


Repeat Visit
When visit the site for the again your cache will start being utilized.  You can see that items that are  allowed to be cached are returned form the local cache.  Looking at the sent and received columns you can also see that no data was sent or retrieved for this.  You can get this behavior by pressing enter in the address bar or clicking on a link to the page.



Refreshing
When you refresh a page using F5 or clicking the refresh icon, you force internet explorer to request a new version of the files.  You would then expect that all the files be retrieved from the server as it did in the first visit, but it does not.  Instead you get all cache allowed items returned with a code 304.  This indicates that the item has not been modified since the last visit.  This has the advantage that only a small "version check" is sent and retrieved form the web server.


Clearing the cache
To clear all the local cache you need to delete all the Temporary Internet files.  From Internet Explorer - Internet Options - Browsing History - Delete - Check Temporary Internet Files.  Reloading the web page will the return all items from the web server as it did on the first visit.

This concludes the section cover cache on the user's local machine.  This is however not the end of the caching story.  There are additional place where the web content can be cached.  All of which are transparent to the user.   If the item is retrieved form a proxy cache or a web server cache, it still is retrieved externally.

01 July 2011

HTTP Status Codes Quick Guide

It is inevitable that you will run into the status codes and you will not know what they mean.  Also you might want the expanded clarification for it from the RFC at the www.w3.org

Here  is a quick reference with links to the RFC

Informational
100 : Continue
101 : Switching Protocols

Successful
200 : OK
201 : Created
202 : Accepted
203 : Non-Authoritative Information
204 : No Content
205 : Reset Content
206 : Partial Content

Redirection
300 : Multiple Choices
301 : Moved Permanently
302 : Found
303 : See Other
304 : Not Modified
305 : Use Proxy
307 : Temporary Redirect

Client Errors 
400 : Bad Request
401 : Unauthorized
402 : Payment Required
403 : Forbidden
404 : Not Found
405 : Method Not Allowed
406 : Not Acceptable
407 : Proxy Authentication Required
408 : Request Time-out
409 : Conflict
410 : Gone
411 : Length Required
412 : Precondition Failed
413 : Request Entity Too Large
414 : Request-URI Too Large
415 : Unsupported Media Type
416 : Requested range not satisfiable
417 : Expectation Failed

Server Error
500 : Internal Server Error
501 : Not Implemented
502 : Bad Gateway
503 : Service Unavailable
504 : Gateway Time-out
505 : HTTP Version not supported

Here is the full RFC for Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616)