sys.webforms.pagerequestmanagertimeoutexception: The server request timed out

Har problem.

När kontor som har bbb som internet leverantör ansluter till vår site får de följande felmeddelande på siter som använder ajax.net.

sys.webforms.pagerequestmanagertimeoutexception: The server request timed out

Ingen trafik kommer till vår server på siter som använder ajax.net. Användarna kan dock kommunicera med servern när det inte är sidor som använder ajax.net. T ex kan de logga in.

Av många många användare är det endast ett fåtal som upplever detta problem och det de har gemensamt är bredbandsbolaget som internetleverantör.

Tacksam för svar.

Har löst det genom att tabort ajax.net för vissa kunder dock har jag fått lite input från ett annat forum.

The problem definitely isn't on your end. The ISP probably installed a more aggressive proxy or content filtering that's interfering.

If you can, get them to relax that type of thing for requests with the request header "x-microsoftajax". Partial postbacks all have that header variable.

Denna information kan ju vara intressant om nån fler upplever problemet. Så kan vi gemensamt trycka på de ISP:er det berör.

Jag har löst x-microsoftajax-problemet, om det verkligen är det som strular.

Har postat lösningen här

http://forums.asp.net/p/1144748/1850717.aspx

Tack emmission verkar som att din lösning funkar! Kanon :)

emission skrev:

Jag har löst x-microsoftajax-problemet, om det verkligen är det som strular.
Har postat lösningen här
http://forums.asp.net/p/1144748/1850717.aspx

Såg riktigt lovande ut men jag kom inte riktigt hela vägen.
Jag lade till javascriptet på sidan och C#-koden i
void Application_BeginRequest(Object Sender, EventArgs e)
i Global.asax

HttpRequest request = HttpContext.Current.Request;
            if (request.Headers["X-MicrosoftAjax"] == null && request.Form["__MicrosoftAjax"] != null)
            {
                ArrayList list = new ArrayList();
                list.Add(request.Form["__MicrosoftAjax"]);
                Type t = request.Headers.GetType();
                t.InvokeMember("MakeReadWrite", BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Instance, null, request.Headers, null);
                t.InvokeMember("InvalidateCachedArrays", BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Instance, null, request.Headers, null);
                t.InvokeMember("BaseSet", BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Instance, null, request.Headers, new object[] { "X-MicrosoftAjax", list });
                t.InvokeMember("MakeReadOnly", BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Instance, null, request.Headers, null);
            }

och jag får verkligen en X-MicrosoftAjax header och Ajax.net verkar fatta det.

Det är bara det att jag ändå får:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed...
Details: Error parsing near 'sdfsdfsdfsdf=|64'.
Där sdfsdfsdf egentligen är slutet på ViewStaten.

När jag sedan tittar på vad jag verkligen får tillbaka från servern så ser jag några små skillnader. När det fungerar (när jag inte går via firewallen som tar bort x-microsoft-ajax headern) så får jag:
Content-Type: text/plain; charset=utf-8

1c3a5
115566|updatePanel|ctl00_mainPlaceHolder_UpdatePanel2|

och när det inte fungerar:
Content-Type: text/plain; charset=utf-8

115566|updatePanel|ctl00_mainPlaceHolder_UpdatePanel2|

På något vis så har 1c3a5 blivit bortskalat. Någon av er som har koll på varför eller ens vad 1c3a5 är för något i detta sammanhang?

Om ni har någon annan lösning på problemet med firewalls som tar bort x-microsoftajax headern så är jag väldigt intresserad av det också.

Tack på förhand!

Jag tar en titt på det här i helgen. Lustigt att responsen skulle kunna påverkas av att man leker lite med requesten.

Är det verkligen samma sida/request. Hex-koden som finns med i exempel 1 är en längdangivelse som används när sidan skickas i chunks. Kanske är brandväggen så taskig att den tar bort Transfer-Encoding-headern också, får då blir det nog knasigt.

Jag tror du är något på spåret. Sidan passerar nämligen en firewall/tunnel/reverse proxy som inte fullt ut implementerat HTTP1.1. Tack för tipset!