[Updated on February 22nd, 2010 – adding additional values for WSS 4.0]
Today I have been working on a support case where customer experienced exceptions in sharepoint when passing in specific query string parameters which are evaluated by his web parts. The URL looked similar to this:
http://servername/Pages/MyPage.aspx?ID=<number>
The problem here is caused by the fact that the customer used a reserved query string parameter. When creating the SPContext object SharePoint evaluates the following query string parameters if provided:
- FeatureId
- ListTemplate
- List
- ID
- VersionNo
- ContentTypeId
- RootFolder
- View
- FolderCTID
- Mode
- Type
With WSS 4.0 the following query string parameters need to be added to the list:
- PageVersion
- IsDlg
- Title
- _V3List_
To ensure that the creation of the SPContext object does not fail your application should ensure that your query string parameters are different from those listed above.
Permalink
PingBack from http://emadmagdy.wordpress.com/2009/01/30/good-links-january-30-2009/
Permalink
I noticed that when I used the ID parameter in the query string, it would work for numbers but not letters. ?ID=1234 would render correctly, but ?ID=123A causes the page to crash. Any ideas? I'm using SharePoint 2010 and a query string filter web part to filter a document library web part.
Permalink
Hi Vertigo,
as indicated these parameters are reserved and internally used for a special purpose.
E.g. the ID parameter is undergoing a string-to-int conversion to map it to a list item ID.
If this parameter now contain non-numeric values this string-to-int conversion will fail and you will get an exception.
Using any of these parameters in your code can lead to unpredictable results.
Cheers,
Stefan
Permalink
Truly unpredictable. We are used the parameter ID in four or five querystrings sometimes as the first parameter other times as the second or third parameter. We had an issue with only one usage where the any user without Site Collection Admin rights would get an Access Denied error thrown on attempting to open that page. But when the parameter name was changed to ListItemId then the page worked as designed. However none of the other pages with that parameter in the call to open the window responded in that fashion. Truly a model of SharePoint's consistency
Permalink
Is there a definitive list anywhere of the query string parameters that we are allowed to use?
Permalink
Hi Adrian,
that is impossible as there is an endless list of allowed query string parameters.
Cheers,
Stefan
Permalink
Is there a definitive list anywhere of the query string parameters that we are allowed to use?
Permalink
Hi Braham,
I doubt that there is enough disk space available world wide to store the list of all allowed query string parameter names.
Cheers,
Stefan
Permalink
While the question is silly, neither answer is productive.
The key to finding a solution is to recognize that the reserved list must be avoided as the name of the Querystring parameter, yet you are still able to filter against the ID column, for example.
Simply use a "friendly" name for the actual Querystring parameter. If your list is Customers and you want to filter your by the ID field, name your Querystring parameter CustomerId or cid or … (anything but a name on the reserved word list).
In the configuration of your connection, use ID in the Consumer Field Name. Using this approach, the expected results are achieved consistently.
Permalink
Mortacci tuaaa!
Yes, but as one reads the parameter from querystring?
Permalink
Hi Io,
you can read them – but you should not set these query string parameters.
Cheers,
Stefan
Permalink
What i understand that even for adding a new query string parm, we should used some different name other than which are mentioned in the post
Permalink
Hi Mohammad, your understanding is correct.
Permalink
This help me with a SharePoint 2013 issue. I was passing "Title" as a parameter in the url. I changed it to JobTitle and everything works!
Permalink
If you pass a parameter ID, you should also pass corresponding ListID…. Then it does recognize it as legitimate query string, even if you do not care about the ListId…
Quite late in the discussion but perhaps helps someone