[C#/ASP.Net] Error 500, maar alleen in Firefox 4

[PdeBie]

Ik heb een textbox en een listbox binnen een updatepanel staan. Afhankelijk van de input van de textbox, wordt de listbox gevuld vanuit de codebehind. Echter, in Firefox 4 werkt dit niet.

Wanneer ik m'n request en reponse met Fiddler bekijk, zie ik dat de pagina een error 500 krijgt. Deze krijg ik echter niet met andere browsers (getest met Chrome, IE9 en Firefox 3.6). Daar werkt de site wel naar behoren.

zie hier het request van de site en de reponse van Fiddler (de url's zijn verborgen, dit ivm eisen van mijn werk m.b.t. posts op forums).

Request:

code:

POST http://url HTTP/1.1
Host: url
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
X-Requested-With: XMLHttpRequest
X-MicrosoftAjax: Delta=true
Cache-Control: no-cache, no-cache
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Referer: url
Content-Length: 18618
Cookie: __utma=98739785.2095233637.1272893197.1272893197.1297765462.2; __utmz=98739785.1297765462.2.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); .ASPXANONYMOUS=7gmRMMthzAEkAAAANzUzZjIwYjktZDU4Yi00MjRmLWFlMTItZmZiMTU2M2JjODQ40; __utma=139705254.31048782.1308128005.1308569327.1308572229.5; __utmz=139705254.1308128005.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmv=139705254.8888; language=nl-NL; __utmb=139705254.3.10.1308572229; __utmc=139705254; authentication=DNN; .DOTNETNUKE=57AC26D7D92659A4793405DD1FCD91B66EAD456A8049867D254FA1A4A1E501628BCAFF9D38862AE219204FA878CB9057C00452D9565890282E5D4843D3BCBB7F996D9682F76633084704A35098B74DC65F0C36F3B63747167D4A270F7FC5AFBF91EA7A62975EB5F4B508906D; DNNEvents977=EventList.ascx; DNNEvents=EventCategory977=; ASP.NET_SessionId=krj3rvin4aozwm5ipeljbrup
Pragma: no-cache

Response (firefox 4):

code:

HTTP/1.1 200 OK
Date: Mon, 20 Jun 2011 12:16:03 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-UA-Compatible: IE=Edge
X-AspNet-Version: 4.0.30319
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/plain; charset=utf-8
Content-Length: 13

0|error|500||

En hier de response van IE9:

code:

HTTP/1.1 200 OK
Date: Mon, 20 Jun 2011 12:41:28 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-UA-Compatible: IE=Edge
X-AspNet-Version: 4.0.30319
Set-Cookie: portalaliasid=20055239DD343F8AAE1C5DBDCF9E52E28C2D246A03A254A4380A17359062E492BDC02325ADA93C9F67851719F0DD68AC832D93924C0E742D1E5C70E63AAE624A26BE905D17CFF70BDB9F39F0905639F72461F425B2B63FFF7884579A73854C2C0359EFC7BF658B67E1C01B44C5C6B7F3CAD24EBC; expires=Mon, 20-Jun-2011 12:42:28 GMT; path=/; HttpOnly
Set-Cookie: portalroles=98EDB3BA8B19763D04B3E4EE736FFDA7CF66BC6C50DC016D3AF13163CB031E1E647F6036F49F687900D62752D66B1418FF146B5B33B19E420C354ABC8A8C6F918E16229FCECA694DC46D769459004289D939F6C0BF5F95A0A6503DA8A2DC9B02040443F077CD8D886F2419F4E33195B6480DD8B73F7B91A3B9FED116B9E94789A2AF998BE0544DE3DF2E971F192E566CE00D881903C69E60C41B4CEFBBB23D4EFA4A862B6A69E082FD3BEB61; expires=Mon, 20-Jun-2011 12:42:28 GMT; path=/; HttpOnly
Set-Cookie: language=nl-NL; path=/; HttpOnly
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/plain; charset=utf-8
Content-Length: 107272

...... html .......

Het gekke is nu echter dat lokaal alles werkt (veelgebruikt excuus van developers volgens mij ). Ook in Firefox 4.
Een complete release naar de server mocht niets baten. En ik zie lokaal in de response van FF4 een keurige html terug komen.

Na wat google-werk kwam ik de volgende post tegen:
http://stackoverflow.com/...5/firefox-and-updatepanel
Echter is dit voor een hele oude FF versie en de oplossing heeft mij ook niet geholpen.

Wie o wie heeft er ideeen? Ik weet het even niet meer

[Niemand_Anders]

En welke foutmelding (stacktrace) geeft jouw webserver dan? Heb je al eens het request van IE9 met die van FF4 vergeleken (inclusief eventuele post)..

En waarom zoek jij het probleem client sided als je een server sided error (500) terug krijgt?

[BasieP]

um even dat ik niet gek ben hoor:

je browser maakt het Request aan. Dus deze is browser specifiek. De response maakt de server aan en zou altijd hetzelfde moeten zijn (mits je request niet vraagt om een specifiek response, bijv. bij caching)

Dus wat jij post (response ff4 en response IE9) vind ik een beetje appart. Daar zou (bijna) geen verschil in moeten zitten.


Trouwens zie ik FF4 ook gewoon een 200 OK geven..

[Voor 8% gewijzigd door BasieP op 20-06-2011 15:14]

[DoDo]

Als je de custom errors mode uit zet op de server, krijg je ipv een 500 error de volledige error + stacktrace.

[PdeBie]

BasieP schreef op maandag 20 juni 2011 @ 15:12:
De response maakt de server aan en zou altijd hetzelfde moeten zijn (mits je request niet vraagt om een specifiek response, bijv. bij caching)
Dus wat jij post (response ff4 en response IE9) vind ik een beetje appart. Daar zou (bijna) geen verschil in moeten zitten.
Trouwens zie ik FF4 ook gewoon een 200 OK geven..

vandaar mijn smillie. Dat is het hele frustrerende ervan. Hij geeft een 200 OK terug, maar in de daadwerkelijke response een 500 ERROR.

DoDo schreef op maandag 20 juni 2011 @ 15:23:
Als je de custom errors mode uit zet op de server, krijg je ipv een 500 error de volledige error + stacktrace.

Custom Errors staat uit op de server, dit had ik al geprobeerd. Maar krijg geen error terug. Ik zie gewoon de pagina zoals hij voor de POST was. Echter is de listbox niet gevuld.

Niemand_Anders schreef op maandag 20 juni 2011 @ 15:12:
En welke foutmelding (stacktrace) geeft jouw webserver dan? Heb je al eens het request van IE9 met die van FF4 vergeleken (inclusief eventuele post)..

Ik krijg geen stacktrace terug van de webserver, dat is het frustrerende. Als ik beide requests vergelijk zie ik geen spannende dingen waar iets mis mee zou kunnen zijn. Zie hieronder het request vanuit IE9

code:

POST http://url HTTP/1.1
Host: url
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept: */*
Accept-Language: nl
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
X-MicrosoftAjax: Delta=true
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Referer: http://url
Content-Length: 2193
Connection: Keep-Alive
Pragma: no-cache

Misschien handig ter informatie (al denk ik dat het weinig verschil uitmaakt).
Deze pagina draait binnen een DotNetNuke omgeving en de genoemde functionaliteit staat op een usercontrol, welke ingeladen word op een pagina.

[Voor 3% gewijzigd door PdeBie op 20-06-2011 15:38]

[PdeBie]

ter info:
Ik heb iets kunnen vinden in de log-viewer van DotNetNuke. Daar lijkt inderdaad een 500 ERROR afgevangen te worden. Ik ga dit eerst uitzoeken. Mocht ik de oplossing hebben, laat ik het hier weten. Anders volgen er vanzelf nog vragen.

Alvast bedankt voor het mee denken.

[BasieP]

je gebruikt ajax om je request te doen. Het is normaal dat je dan geen stacktrace terug krijgt. Je pagina veranderd namelijk niet.

Je kan in firefox gewoon je complete response terugzien in firebug. Hierin zou wel een stacktrace moeten staan.
Mocht je geen firebug hebben of het lukt niet kan je ook nog iets als wireshark gebruiken. Daarmee kan je ook alles zien.

Dat is het hele frustrerende ervan. Hij geeft een 200 OK terug, maar in de daadwerkelijke response een 500 ERROR.

Je response is een 200 OK.
Period.

Dat de tekst binnen die 200 OK pagina een 'Je hebt een error 500' is, is natuurlijk prima. Dit maakt de pagina nog geen 500 Internal server error pagina.
(als je me nog volgt)

[PdeBie]

Firebug net even geraadpleegd, maar zie geen stacktrace, maar een keurige html.

Ik denk eerlijk gezegd dat dit komt door DotNetNuke. Die vangt namelijk het een en ander af zie ik in de LogViewer en ik denk dat DNN dit vervolgens anders afhandelt dan een 'normale' webapplicatie.

In de Logviewer zie ik overigens een duidelijke error i.c.m. stacktrace.

code:

InnerException: Input string was not in a correct format.

Dus het zit wel duidelijk ergens mis in de code-behind. Dus hier kan ik rustig verder mee werken.

Bedankt voor de hulp en het mee denken in ieder geval. De tips m.b.t. firebug etc. komen vast nog wel vaker van pas

(blijf het overigens wel raar vinden dat ik dit probleem lokaal niet heb )

[Voor 5% gewijzigd door PdeBie op 20-06-2011 16:33]

[Niemand_Anders]

BasieP schreef op maandag 20 juni 2011 @ 16:16:
je gebruikt ajax om je request te doen. Het is normaal dat je dan geen stacktrace terug krijgt. Je pagina veranderd namelijk niet.

Sorry? Een ajax update is voor jouw webserver helemaal niet anders dan een regulier verzoek. In beide gevallen komt er een request binnen en moet de server een response terug geven.

Echter als je via xmlHttpRequest een verzoek doet, zul je inderdaad niet in je browser de stacktrace zien. Dat heeft niets met de server te maken, maar met het feit dat jij json of xml verwacht en dan ineens een html response terug krijgt.

Maar als jij je global_asa gewoon een handler op Application.Error (Application_Error methode) zet en deze de foutmelding logt heb je gewoon netjes een stacktrace. Nog beter is om de fout af te handelen waar het fout gaat zodat je bij de fout ook een context hebt (input argumenten) en je dus gemakkelijk het probleem kunt reproduceren.

Overigens zou de TS ook even naar trace.axd kunnen browsen. Deze logt ook de stacktrace samen met veel parameters. Aangezien het probleem alleen lijkt te spelen op een remote server moet je de call naar trace.axd wel expliciet toestaan. Vergeet nadat je het probleem hebt verholpen niet om deze beveiliging weer te herstellen..

[__fred__]

aangezien het een post request is, zou de post-data ook wel aardig zijn.

ik gok gezien de foutmelding een foutje in het parsen van een kommagetal of datum/tijd. ik zou de post data tussen ff4 en ie9 vergelijken.