Oh hey I have a blog, totally forgot about that. Its been busy here lately, but that is no excuse to neglect my blog. So in light of this, I am going to post something I used recently when passing data to a generic handler via query string was just not cutting it. Passing data via query string has limitation in the length of data you can send. Here is a in depth post on these limitations http://stackoverflow.com/questions/812925/what-is-the-maximum-possible-length-of-a-query-string
I’ll sum up these limitations briefly:
- Internet Explorer
- 2,038 character limit, boo hiss boo
- 65,536, but could work for more
- 80,000 character limit, but could work for more
- 190,000 character limit, but could work for more
- 4,000 character limit, but could work for more
- IIS – Internet Information Server
- 16,384, but could work for more
- IE accepts less, but the server can accept more. Huh?
Since we have to make our web app work with IE there is no choice but to somehow shoe horn our parameters to be passed to generic methods. Instead of using query strings, another approach would be to use the IRequireSessionState or IReadOnlySessionState interface. For my generic handler I used the IReadOnlySessionState interface. In the code behind calling the generic handler, I stuffed the data I needed into session variables, Session["Key"] = value;
For the generic handler, I had it implement the IReadOnlySessionState. I didn’t want it to do anything, but to read those session variables.
Here’s what I did:
public class DownloadTemplate : IHttpHandler, IReadOnlySessionState
public void ProcessRequest(HttpContext context)
if (context.Session["ExportedUnitTemplateName"] != null && context.Session["ExportedUnitTemplateSettings"] != null)
string template = context.Session["ExportedUnitTemplateName"].ToString();
string settingString = context.Session["ExportedUnitTemplateSettings"].ToString();
So, I can practically send any type of object I wanted to my handlers and processed that data according to business rules. Well, till next time.