Default Web Ports

echo                      7
daytime              13
qotd                     17 (Quote of the Day)
ftp                         21
telnet                   23
smtp                     25
time                      37
nameserver       53
nicname              43 (Who Is)
gopher                 70
finger                    79
WWW                    80

 

DNS – Maintain mapping between domain names and IPs

http://www.google.com/hi.html -> Browser makes call to DNS servers to get related IP and then will send the request to that IP for hi.html file. Cookies (piece of text that gets stored in the machine as key-value pair) will be transferred between browser to server and vice version as part of headers.

Performance impact of iFrame

Avoid using iframe for performance reasons, read more @

http://www.stevesouders.com/blog/2009/06/03/using-iframes-sparingly/

Using this in some places can not be avoided like if we want to access an https url from a http page which is not accepted. So for handling authentication on AJAX from a http page needs a blank iframe with action to https page and method attribute. AJAX request will be submitted to iframe (intern https url, can be .net generic handler) and on server set the cookies and return the blank response to iframe and on window onload event of iframe we can do neccessary changes on parent page by directly accessing cookies through javascript to know authentication success or failure.

Cookie – Interesting stuff

The cookie spec recommends a minimum of 20 cookies per domain each of which is at least 4096 byes in size. If that limit is exceeded, different browsers do different things.

Want to see how cookie limits work in specific browsers? Click on the following link:

http://www.opensocialpalooza.com/lotsacookies.aspx

When you browse to this page, 100 domain cookies (.opensocialpalooza.com) and 100 subdomain (www.opensocialpalooza.com) cookies are dropped. If you hit refresh, the returned cookies will be displayed in the list box on the page, along with the counts of the domain and subdomain cookies in the request. Here are the results of a quick test of the different browsers:

1. Non-Updated IE 6.0 – 20 domain and 20 subdomain cookies – 40 total – with the last 20 of each returned
2. Updated IE 7.0 – 50 domain and 50 subdomain cookies – 100 total – with the last 50 of each returned
3. Firefox 2.0.0.11 – 49 domain and 1 subdomain cookie – 50 total on first request (51 on later requests) – with a random assortment of domain cookies and the last subdomain cookie written
4. Firefox 1.0.0 – 49 domain and 1 subdomain cookie – 50 total on first request (51 on later requests) – with a random assortment of domain cookies and the last subdomain cookie written
5. Safari Mac OS X Tiger/Windows/iPhone – 100 domain and 100 subdomain cookies – all written cookies are returned. Safari does not look like it will be a problem for total number of cookies for future.

Due to the limits on cookies – unpatched IE 6.0 is clearly the greatest risk and putting cookies in subdomains will help with that immediate limit. If we do exceed that limit inadvertently – then the fix for IE is to write the cookies again – the last written cookie wins in many versions of IE.

Beyond the limit of the number of cookies permitted in different browsers there are also limits on the server side. In particular IIS 6.0 and IIS 7.0 have a maximum size of 16K bytes. Since cookies are transferred in HTTP headers this limit also impacts cookies. Depending on what else is in the HTTP header (user agent string, authorization headers, encoding, content length, content type, etc) the total size, including cookies has to be under 16K on a default IIS limitation. This means while the HTTP cookie spec in theory permits 20 cookies of 4096 bytes, in practice no more than 3 cookies that size can be transmitted when the server is IIS

Best Practices –

1. Create as few new cookies as possible, and add information to existing cookies if possible.
2. Use session cookies instead of persistent cookies. If an error is made in a session cookie the user may not be able to access the site until the browser is restarted. If an error is made in a persistent cookie, the user may not be able to access the site until the cookie expires or until the user clears cookies. Telling millions of users to clear their cookies is impractical, so avoid persistent cookies if at all possible.
3. Cookies should always the last choice of how to do something – never the first choice. Every browser treats cookies differently and has different limits. The servers have hard limits on the size of cookies and form of cookies they will accept – it is very possible to drop cookies in a response that cause the server to fail when a request is returned. In that case the request will fail with a 400 Bad Request error at the kernel layer, and you have no way to return a response with a different set of cookies. At that point you will have DOSed your own site