Aaron Lewis
Top achievements
Rank 2
Rank 2
Aaron Lewis
asked on 19 Jun 2009, 08:07 PM
Hi all,
After a lot of coffee, angry users, and frustration at finding the dialogs for the Q1 2009 SP2 working great on my development machine, but not on IIS 7, I finally found the solution to the problem. Now, if you search these forums, you will find other possible problems that might be applicable to you. For example, you might need to change the dialoghandler.aspx references under system.webServer in your web.config to dialoghandler.axd. That seems to have helped some.
In my case, however, none of the solutions I tried on the forums made a dent. It wasn't until I tried loading the dialogs from the editor while logged in to the web server, where I have failed request tracing enabled (which only displays detailed information if you're accessing your site locally).
Turns out, if you have request filtering enabled, and you have a maximum querystring length set to, say, the neighborhood of 500, the web server will truncate that gigantic querystring that the dialogs are passed by the editor (and, I'm assuming, other controls).
To see if this is what you are running into, and to resolve it if it is, do the following:
1. Open notepad as an administrator.
2. Open applicationHost.config in c:\windows\system32\inetsrv\config
3. Do a search for maxUrl and maxQueryString. They'll be under the requestFiltering section of the file, in the requestLimits node.
For me, setting the maxQueryString to 1000 did the trick. maxUrl will need to be at least that, since it'll include host and path information, as well.
For me, the worst part was that ASP.Net wasn't ever getting the error since the request was being trapped by a native module higher up the food chain, and as far as I knew, it was a simple 404. Turns out it was a 404.something else, a .13 I think.
Anyway, I hope this helps someone butting heads with the problem. Yesterday was pretty stressful for me. GP's a high-load site with a lot of members that expect I won't break stuff with every push! =)
After a lot of coffee, angry users, and frustration at finding the dialogs for the Q1 2009 SP2 working great on my development machine, but not on IIS 7, I finally found the solution to the problem. Now, if you search these forums, you will find other possible problems that might be applicable to you. For example, you might need to change the dialoghandler.aspx references under system.webServer in your web.config to dialoghandler.axd. That seems to have helped some.
In my case, however, none of the solutions I tried on the forums made a dent. It wasn't until I tried loading the dialogs from the editor while logged in to the web server, where I have failed request tracing enabled (which only displays detailed information if you're accessing your site locally).
Turns out, if you have request filtering enabled, and you have a maximum querystring length set to, say, the neighborhood of 500, the web server will truncate that gigantic querystring that the dialogs are passed by the editor (and, I'm assuming, other controls).
To see if this is what you are running into, and to resolve it if it is, do the following:
1. Open notepad as an administrator.
2. Open applicationHost.config in c:\windows\system32\inetsrv\config
3. Do a search for maxUrl and maxQueryString. They'll be under the requestFiltering section of the file, in the requestLimits node.
For me, setting the maxQueryString to 1000 did the trick. maxUrl will need to be at least that, since it'll include host and path information, as well.
For me, the worst part was that ASP.Net wasn't ever getting the error since the request was being trapped by a native module higher up the food chain, and as far as I knew, it was a simple 404. Turns out it was a 404.something else, a .13 I think.
Anyway, I hope this helps someone butting heads with the problem. Yesterday was pretty stressful for me. GP's a high-load site with a lot of members that expect I won't break stuff with every push! =)
5 Answers, 1 is accepted
0
Hi,
We have had similar reports in the past and we generally recommend that the URL limit be set to 2000 characters. There is no specific standard on the maximum length of URLs or the querystring. Since all browsers allow at least 2000 characters, we have set this to be the maximum. If you are using a shared hosting or some other application (e.g. 3rd party firewall) is blocking the long URLs, we offer the following workaround:
You need to add the following code to your page. It runs when the editor is loaded in the browser and sets the maximum URL length for the dialogs (in this case 1000 characters):
It is not recommended to use it because this is not part of the public editor API. This means that we might change the way it works in a future version of the editor, which means problems if you decide to upgrade. You will need to test that this code works after each update. We will consider adding it to the public editor API for the next RadControls release so it can be included in the support resources (documentation).
Regards,
Lini
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
We have had similar reports in the past and we generally recommend that the URL limit be set to 2000 characters. There is no specific standard on the maximum length of URLs or the querystring. Since all browsers allow at least 2000 characters, we have set this to be the maximum. If you are using a shared hosting or some other application (e.g. 3rd party firewall) is blocking the long URLs, we offer the following workaround:
| <script type="text/javascript"> |
| function setUrlLength(editor) |
| { |
| editor.get_dialogOpener()._dialogUrlLengthLimit = 1000; |
| } |
| </script> |
| <telerik:RadEditor ID="RadEditor1" runat="Server" OnClientLoad="setUrlLength" .../> |
You need to add the following code to your page. It runs when the editor is loaded in the browser and sets the maximum URL length for the dialogs (in this case 1000 characters):
It is not recommended to use it because this is not part of the public editor API. This means that we might change the way it works in a future version of the editor, which means problems if you decide to upgrade. You will need to test that this code works after each update. We will consider adding it to the public editor API for the next RadControls release so it can be included in the support resources (documentation).
Regards,
Lini
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
Steve
Top achievements
Rank 2
Rank 2
answered on 14 Sep 2009, 07:03 PM
OK, I've read a bunch of posts of people having the "Web.config registration missing" error with RadEditor, including this one which I was hoping was going to do it for me, but did not. Here's my situation:
- Running site under IIS 7.0
- Have this in my web.config httpHandlers section (and no other handler that looks like it would override this setting):
<
add path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler" verb="*" validate="false" />
- Have this in my web.config <system.webServer> "handlers" section:
<
add name="Telerik_Web_UI_DialogHandler_aspx" verb="*" preCondition="integratedMode" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler" />
- I looked on the webserver machine for the applicationHost.config file, looking for the maxUrl and/or maxQueryString nodes. Neither were found.
- I tried adding the javascript function you suggested for handling the RadEditor's "OnClientLoad" event.
NOTHING WORKED. After getting the error prompt of "Web.config registration missing", the actual RadWindow that is supposed to be the editor dialog shows either a "SessionPageStatePersister" error or a 404 error. In either case, it looks like the system is looking for the Telerik.Web.UI.DialogHandler.aspx file in whatever folder my aspx page is in that has the RadEditor on it.
Oh by the way, pretty much EXACT same code base works fine under IIS 6.0.
0
Steve
Top achievements
Rank 2
Rank 2
answered on 17 Sep 2009, 05:13 AM
Forget it. It appeared to be related not to the IIS version, but RadCompression. We are using it on the site that we were having issues on. I found a specific fix to allow RadEditor dialogs to work on a site using RadCompression. You should think about posting this info so it is clearly visible on the RadEditor documentation.
0
Hi Steve,
Can you please share with the community the specific fix that you found for the RadCompression related problem? After that we will update the KB article.
Greetings,
Rumen
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Can you please share with the community the specific fix that you found for the RadCompression related problem? After that we will update the KB article.
Greetings,
Rumen
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
Steve
Top achievements
Rank 2
Rank 2
answered on 17 Sep 2009, 01:33 PM
Actually, it was a solution previously posted. Here's the link: http://www.telerik.com/support/kb/aspnet-ajax/editor/session-in-dialogs.aspx