Sunday, November 27, 2016

Cookie limits - browser side

If you search the net for 'cookie limits', you'll find this site (or variations of it). I was baffled that max total cookies size is a 'guess' within a fairly large interval. So I set to write my own version and hope to get more accurate numbers.

Here  is the result:

It turned out the limits guessed were accurate already (no variation interval was necessary). But it was interesting to learn more about cookies and javascript. Here are a few notes.
  • JavaScript support for cookies sucks, it's a weird mechanism. Setting a cookie is done by setting a property, document.cookie, but reading back that property returns all cookies set (just names and values, even though cookies set could have other properties like path or expiration dates)
  • If you set cookies from JavaScript, don't forget to remember the names of cookies set in a separate list! If you set cookies with values that go over the browser limit per domain, browsers like IE/Edge will clear up the property document.cookie, and you'd have no way to enumerate existing cookies (to know what to delete before being able to set new cookies). Fwiw, this behavior is browser dependent, Chrome/FireFox will drop oldest cookies instead...
  • IE support for JavaScript sucks. In IE11, string.startsWith(), string.repeat() are not implemented, delegates var f1 = () => {dosomething();} are not understood, etc. Edge is better in this regard.
  • Chrome is silly, not allowing using cookies when scripts are run from file:// locations.
  • IE & Edge have very low limits for total cookies size. You probably don't want to send 10k cookies with every http request, but I've seen websites hitting these limits... 15k would have been more reasonable (and closer to the 16k default limit of header sizes in server side). On the plus side, 5k per cookie is better than the ~4k of all other browsers (and I've seen websites hitting that limit in other browser, too)(
Anyway, here are the results for cookies limits for the major browsers as of writing this article:

Browser   Max bytes/cookie   Max cookies   Max total bytes for cookies
IE11 & Edge 5117 50 2*5117 = 10234
Chrome 54 4096 180 180*4096 = 737280
Firefox r50 4097 150 150*4097 = 614550
Opera 41 4096 180 180*4096 = 737280

Thursday, November 24, 2016

Cookie limits - the server side story

If you search the net for 'cookie limits', you'll find this site (or variations of it) that list browser-side limits for cookies for a couple of browsers.
RFC2965 will tell you a browser should support at least 20 cookies of size 4096 bytes per cookie, but browsers usually support higher limits. E.g. Chrome supports 180 cookies of size 4096 bytes, per domain, with no limits for the total size of all cookies. That makes 720Kb of data that is allowed by Chrome in each request.

In reality, even if you insist of sending that crazy big amount of data with every http request, you'll discover it's impossible to use that many cookies. Depending on the server accessed, you may be able to use only max 3 cookies of size 4096 bytes! Why? Because there is another side of the story - the servers you are accessing will also limit your use of cookies sizes.

Those limits depends from http server to server, and the server response if you make larger requests varies, too. Here are some examples:
  • - throws SocketException / ConnectionForcefullyClosedByRemoteServer after ~16k max cookies
  • - Starts returning "400 Bad Request – Request Too Long. HTTP Error 400. The size of the request headers is too long" after max ~15k cookies - Starts returning 413 Request Entity Too Large after ~15k cookies
  • - Starts returning 400 Bad Request after ~7.5k
  • - Accepts requests up to ~65k, after that returns 400 Bad Request 
  • - Accepts about ~80k after that starts returning 400, 502 or  throws WebException/MessageLengthLimitExceeded (seems dependent on the number of cookies, too)
Per, IIS Server defines two configuration settings, MaxFieldLength and MaxRequestBytes that limits the size of the http request headers that are accepted. This includes things like the RequestUrl being accessed, the User-Agent string, AAD authentication tokens, etc, thus limiting the size of Cookies stored in headers, too. For IIS, that limit is 16Kb by default, and can be configured. Probably Apache has similar limits, and website owners may have adjusted the limits.  

If you're writing a web application and use cookies pushing the limits, it's important to know what your server will tolerate on incoming requests.

I wrote an app one can use to test and get an idea of the server limits. You can download it from and invoke it with the http:// Uri of the server to test for parameter. The app makes requests to the server with cookies of various decreasing sizes, trying to narrow down the accepted max cookies size. The output looks like in the picture below.

Saturday, September 5, 2015

Useless router WiFi speeds and maximum Surface Pro 3 Wifi speed

I got puzzled last week by my Surface Pro 3, which usually connects at 60-90Mbps to my router, regardless of which band (2.4 or 5Ghz I choose). I knew Surface 3 had some problems with low WiFi connection speeds when it was released, but since then Microsoft has released drivers and firmware updates that were supposed to fix the problem. I upgraded to an AC router, Surface Pro also has AC adapter, so why am I not seeing better speeds?
My WiFi router is a Netgear Nighthawk R8000, which boasts a 3.2Gbps WiFi speed. That's just for PR, in reality, it has one 2.4GHz band with max 600Mbps and two 5GHz channels, each supporting max 1300Mbps. So, the max speed of connection is limited to the max speed of the band I'm using. But, that's not the end of the story - both my Surface Pro 3 and my wife's laptop connect at maximum 866.5Mbps, and that's when staying 2-3 fests apart from the router. The speed is actually negotiated between the router and the client device. If I move 10 feet away, the speed starts dropping to 700Mbps. If I stay in living room, the speed drops to 80-90Mbps.
Surface 3 Pro has a 'Marvell AVASTAR Wireless-AC Network Controller' Wi-Fi adapter, and based on it's maximum WiFi speed is 867Mbps.
I'm reaching this speed (so Microsoft kept its promise and fixed the low speed problem), but I have to be feet apart from the router to reach it. And even in these ideal conditions I'd need at least 4 Surfaces to saturate the two 5GHz channels plus more WiFi devices connecting on 2.4GHz to reach the advertised router's speed... The router speeds are just a PR gimmick.

Sunday, November 2, 2014

Digital Photo Professional cannot edit CR2 RAW files

Today I spent almost one hour trying to figure out why Canon DPP was not able to edit some pictures I took a while ago. All the pictures in one folder were shown like this:


Notice the glyph on top of each image indicating editing was not allowed.

I searched 3 times the menus for some option to unblock editing, but there was none. I thought of files being read-only on disk, having wrong ACLs. Nothing. Some website suggested for images being edit-protected from the camera to access an unblock option from the Info window, but that was completely empty instead of displaying EXIF info.


It was only happening with images in one folder, so I moved an image out of that folder, but nothing changed.

Hours later I viewed the images in Explorer from a different computer, and then I noticed something odd – why was the CR2 size so small as compared with other pictures? Were they corrupted?


And then it hit me – when I took those pictures the camera battery run out on my 5D III and I had to use my old camera, a Canon 20D. And DPP was not able to open the files from this older camera…

After a little digging on the net, I had the confirmation: Canon has released Digital Photo Professional 4.0, but only for 64-bit computers and only for certain cameras like Canon 5D Mark III. Older camera like Canon 20D are not supported by DPP 4, and instead I had to download the previous version, DPP 3.14 to edit the raw files. It turns out that even new cameras from Canon like 7D mark II are not supported by DPP 4.0, on either 32 or 64-bit Windows. Hopefully Canon will reconsider and add compatibility support for all the cameras when they release a new version of DPP 4…

Thursday, September 18, 2014

How to install Active Directory (AD) tools on Windows 8

Start by installing Remote Server Administrator Tools For Windows 8.1 to get the 'Remote Server Administration Tools' components, then Turn Windows features on/off, and make sure to select 'AD DS Tools'.

This article describes in great details the steps

Sunday, June 1, 2014

My Wi-Fi connection not using full speed of 300Mbps


I have two Netgear Wi-Fi routers that have Wi-Fi connections enabled with speeds up to 300Mbps. However, the laptop, tablet, etc connects to them with speeds usual in the 78-144Mbps range, never over 150Mbps. This didn’t bother me much as these speeds are still over my broadband connection speed (60Mpbs), and I don’t transfer many files between laptop and other computers in the network. But still, why does this happens?

The documentation says “The WNR3500 router will use the channel you selected as the primary channel and expand to the secondary channel (primary channel +4 or -4) to achieve a 40 MHz frame-by-frame bandwidth. The WNR3500 router will detect channel usage and will disable frame-by-frame expansion if the expansion would result in interference with the data transmission of other access points or clients.”

I thought the low speed was caused by router settings. My router had channel 4 set as primary, which left only 4+4=8 as secondary. I thought some interference on channel 8 was preventing it to be used, so I changed the primary to 5, with 1 and 9 now as options for secondary. But that didn’t increase the connection speed.

Today, after digging more, I looked on laptop at adapter’s settings. There, the Channel Width on 2.4GHz range was set to “20 MHz Only”. I set it to Auto, let the laptop reconnect, and voila! Now the speed increased, reaching values in the 270-300Mhz range, as it should have.



It didn’t make sense, why won’t be this set to Auto by default? Then I remembered. It was.

3 years ago I was experiencing frequent connection drops, and a lot of reconnecting – I was not able to maintain a RemoteDesktop connection to work without the laptop pausing for reconnect every couple of minutes. It was really annoying. And it was me who limited the channel width to 20MHz, which seemed to reduce the number of connection drops.

Well, now I have a second Wi-Fi router to extend the range, and the laptop’s connection at 300Mbps seems more reliable now. So I guess I’ll keep the laptop’s channel width back to its default settings.

Unfortunately the Surface RT’s network adaptor doesn’t have a similar setting, so the tablet will have to connect to 150Mbps max. No loss there until Comcast will allow such speeds at reasonable prices.

Wednesday, November 27, 2013

Using Visual SourceSafe 2005 with Visual Studio 2010, Visual Studio 2012 and Visual Studio 2013

Visual SourceSafe is out of mainstream support since 2012 and will be in Extended support until 2017. However, may people use the product past its lifetime dates, if for no other reason at least because they have programs developed originally and stored in VSS databases that will still need maintaining.
Microsoft Visual SourceSafe 2005 will still install on modern computers, and will still integrate with recent version of Visual Studio

Opening projects from source control

Visual SourceSafe 2005 was changed from VSS 6.0 and integrated with the File/Open Project/Solution dialog in Visual Studio. On Windows XP, Vista (and 7, I think), the Open dialog showed a dedicated ‘Visual SourceSafe’ icon in the tray, so it was intuitive to discover the Open from source control functionality. Since then, Windows changed the layout of the Open dialog, and SourceSafe option can only be found if you scroll the folders tree to the top…
Open Project from SourceSafe in VS 2005image
Even worse, the namespace extension providing integration with Explorer and the Open dialogs broke during the years. Here are the options on how to fix the Open From Source Control functionality:

A) Use SourceSafe 6.0 way of opening from source control.

When it integrated with the File/Open dialog, SourceSafe 2005 has set some registry keys that make VSS Integration package in VS hide the OpenFromSourceControl commands under File/SourceControl menu. You can modify the registry and bring back those commands:
1) Using regedit, open the registry and locate under
[HKLM\SOFTWARE\Microsoft\SourceSafe\Namespace Extension]
DisableOpenFromSourceControl == (DWord)1.

2) Change the value to (Dword)0 or delete the value completely. There will be a similar value for SourceSafe Internet provider under Microsoft\SourceSafe\RemoteAccess\Namespace Extension, change that as well
(Note: The values are under Wow6432Node hive on 64-bit machines)
3) Restart Visual Studio and now you should have under File/SourceControl a menu item that allows opening solution from source control.
4) Make sure to select a different location when opening from source control in a new enlistment (the equivalent of “Change Destination Folder” in the open functionality from the OpenProject dialog)

B) Fix the namespace extension.

1) If you installed VSS 2005 RTM and try to navigate the namespace extension you will see there are no items available under SourceSafe node. Clicking on the SourceSafe icons in the tree results in an error message “No such interface supported”

This error has been fixed in the SourceSafe 2005 Update build, so please install VS80-KB943847-X86-INTL (which you should do anyway)
2) Now you should be able to navigate the SourceSafe databases in the File/Open dialog, you should be able to select a solution or project and change the scc location, however, when you’ll try to open the solution Visual Studio will display another error message “The selected file is not a valid solution file”.
Why does this break? Surely you’ve selected a solution file! In order to return the path to the solution to VisualStudio, TDNamespaceExtension.dll which is the NSE deployed by SourceSafe needs to create a URI like msss://SoursafeDatabasePath/~files/PathToTheSolution (there’s more to that, but you get the idea). Unfortunately the MSSS scheme parser is a component implemented by a dll that ships with VisualStudio, so in order to create the parser TDNamespaceExtension looks up in registry under Visual Studio registry hive; as SourceSafe 2005 shipped in the box with Visual Studio 2005 (VS 8.0),  it looks under this registry key
Of course this key does not exist if you install a more recent version of Visual Studio…
For  Sourcesafe to find the correct parser, the TDNamespaceExtension.dll had to be updated to look under the right key. To make VSS work with VS2008 and VS2010 Microsoft released patches to TDNamespaceExtension (e.g. KB976375 is what you can install for VS2010). But for VS2012 and VS2013 Microsoft hasn’t released anymore such updates, probably due to SourceSafe reaching the end of mainstream support. Sad smile
If you have multiple versions of VisualStudio installed (e.g. I have VS2010, VS2012 and VS2013 installed) and have fixed VSS to work with one version of VS you won’t (I have fixed it for VS2010 installing the KB article mentions above) you see this problem in the other versions, because VSS is able to find the parser from that version of VS (from VS2010 in my case).
Anyway, it’s easy to fix the problem manually even without KB articles, by setting a registry value which tells SourceSafe where to locate the MSSS scheme parser. Besides looking under the VS 8.0 hive, TDNamespaceExtension also looks in a common place, under HKCU\Software\Classes\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}
So we can register the parser there, pointing to the current version of Visual Studio you have installed. E.g.:
- Save the content below to a file with .reg extension
- Edit the 12.0 if necessary and replace with the version of VS you have installed
- Double click the file and import it into registry.
Windows Registry Editor Version 5.00
"InprocServer32"="C:\\Program Files\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
@="VAPI Scheme Parser Msss"

Now you should be able to open file from source control using the File/Open/Project without running into the “The selected file is not a valid solution file” error.

Note: The above file worked for me on a 32-bit machine. On my 64-bit machine, I have the VAPI parser registered under multiple locations (I think the last one is written by VS setup and gets copied into 12.0_Config hive on first run); it won't hurt to register it similarly though.

Windows Registry Editor Version 5.00
@="VAPI Scheme Parser Msss"

@="C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"

@="VAPI Scheme Parser Msss"

@="c:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"

"InprocServer32"="C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
@="VAPI Scheme Parser Msss"

"InprocServer32"="C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
@="VAPI Scheme Parser Msss"