[CLOSED] DirectMethod BADRESPONSE: Unterminated string constant or Httphandler Request Failure

[marczin]

In my application I have a tree with ajax method loader.
It works good in my company (intranet), but user outside my organization who logon by FrontEndManager (windows authentication) get random error: BADRESPONSE: Unterminated string constant.
I see in debug that serwer send to user not completed message (the message is cut off in the middle)
I change tree loader and I use httphandler but I also get random error: Request failure (not completed message from server).
Is it connection problem? configuration IIS problem? or web.config problem?
Where is the problem?

[Daniil]

Hi @marczin,

Welcome to the Ext.NET forums!

I think there might be different reasons, but most likely - there is something in IIS settings.
http://forums.iis.net/t/1183906.aspx
http://stackoverflow.com/questions/9...lf-of-the-page

There are more related links on the internet.

It looks there is a Buffer option in IIS that you might need to change.

Also please try with the latest Ext.NET v1 unless you already use the latest. There was a bug fix that, I think, might potentially affect on the issue.

[tylert]

This may be the same issue that I am having:

http://forums.ext.net/showthread.php...RESPONSE-error

We still have this issue pop up from time to time for users. It's hard to debug because I can't recreate the error locally and the error itself only occurs occasionally.

I agree that it may be an IIS issue. If anyone has any more information about this issue please post. Thanks.

Tyler

[Daniil]

Hi Tyler,

Please clarify have you tried to play with the IIS Buffer setting?

[tylert]

Hi Daniil,

Yes, I have tried to change an IIS buffer setting. This one that you've linked to, the ARR Response Buffer, seems to not apply to our context, because we aren't using Application Request Routing (ARR).

Going back through the screenshots I have of this error, I've noticed that sometimes the response message that gets cut off is not even large. If you look at my original post in the other thread, you will see the BADRESPONSE response is actually very short. In other cases, the entire error window is filled with the response text. So it seems unlikely to me that we are hitting a size limit.

I tried to recreate the error through calling the DirectEvent with a simulated slow connection speed using throttling in Chrome-- no luck. Also, I tried disconnecting the connection halfway through receiving the response -- this doesn't recreate this specific error either. I tried killing the IIS process on the server side while the response was being transferred -- again resulting in a different error.

[Daniil]

Unfortunately, I have no certain idea, but there should be a way to determine/debug what exactly cuts a response. Once we determine for absolutely sure what exactly cuts a response, it will become much easier to trouble shoot. The main problem to debug, that the issue happens inconsistently. By the way, how ofter does it happen? You were saying that a customer reported this problem to you, right? Were you ever able to reproduce this problem locally? What server do you use to develop? If Visual Studio Development Server, you might try to switch to IIS (Express or not Express) and, maybe, the issue will pop up eventually on your local machine and it will be easier for you to debug the problem.

Also I would recommend to do stress testing. Maybe, the issue will appear more often.

[tylert]

I agree -- it's very hard to debug because it's inconsistent. Yes, a customer is reporting this error to us. The problem could be related to a particular user's machine or their company's network configuration. Also, our users previously had to use IE in compatibility mode (I know it is not supported by Ext.NET) because of some legacy controls that we have in our application. We just released a new version that will allow our users to stop using compatibility mode and use a new version of IE or other browser, so we're going to see if this error continues to show up in the new version.

We do use IIS in development instead of IIS express. I've tried stress testing and everything else I could think of to try to recreate the problem locally -- which we have never been able to do. If this error continues for our user, we are going to do further testing to see if the problem is isolated to a particular client computer or network.

I will be sure to update here if we find anything. Thanks!

[Daniil]

That is a good plan.

I am closing the thread, but please feel free to update with any new info.