jquery really is eff
in [JavaScript]
|
Prev: JQuery Ajax
Next: Celexa 10 mg, 5mg Celexa, Celexa acne
From: Andrew Poulos on 25 Jul 2010 23:13 On 26/07/2010 12:46 PM, David Mark wrote: > On Jul 25, 10:24 pm, Alan Gutierrez<a...(a)blogometer.com> wrote: >> Andrew Poulos wrote: >>> On 26/07/2010 10:01 AM, Richard Cornford wrote: >>>> Andrew Poulos wrote: >>>>> On 25/07/2010 3:02 PM, David Mark wrote: >>>>>> On Jul 24, 11:27 pm, Alan Gutierrez wrote: >>>>>>> Andrew Poulos wrote: >>>>>>>> It look like the error >>>>>>>> is in jquery. Of course the LMS vendor cannot give me their >>>>>>>> source code. So now I'll be caught between an client and a >>>>>>>> (most likely) quick-stepping LMS vendor. >> >>>>>>> Is their source code obfuscated? What is the error? >> >>>>>> He already said what the error was and Richard pointed out >>>>>> how to track it down (obfuscated or not). >> >>>>> I think I need to retract my assertion that jquery was the cause >>>>> of the issue I was experiencing. >> >>>>> Using Charles I see that there's a "500 Internal Server Error" >>>>> and that "Failed to parse data (org.xml.sax.SAXParseException: >>>>> Open quote is expected for attribute..." >> >>>> Server error responses often have an HTML body, though Charles really >>>> should not be presenting that to an XML parser (which is what SAX is) >>>> unless the response includes a content-type header that says the body is >>>> XML (which would include XHTML, SOAP, etc.). >> >>>> An attempt to - eval - such a response body is the sort of thing that >>>> may produce a "... is undefined" error, though that is less likely than >>>> it producing a syntax error. And it would be odd for any client-side >>>> software to respond to an HTTP status of 500 by attempting to - eval - >>>> the response body. >> >>>> Still, Charles offers the response in raw, text, hex, and headers form >>>> in addition to parsed XML so you can see all of the error response. >> >>>>> So it seems its something in the LMS Vendor's Server??? >> >>>> Assuming that the request parameters were correct, as seeing the LMS >>>> system sending error responses to erroneous requests would not >>>> necessarily represent a fault in the LMS system. >> >>> Testing in the ADL test suites confirms that appropriate data in the >>> appropriate format is being sent at the appropriate time. >> >>> With a bit more error checking and I find that a response from the >>> server contains is >> >>> <?xml version='1.0' encoding='ISO-8859-1'?> >>> <values> >>> <group> >>> <lasterror></lasterror> >>> <returnvalue><![CDATA[]]></returnvalue> >>> </group> >>> </values> >> >> If that is the entire message, then it is well formed according to >> `xmllint`. > > That's not the response in question. > >> >>> and the corresponding error is >> >>> Error: not well-formed >>> Source File:http://www.blah.com.au/Host/scorm1.2server.asp >>> Line: 1 >>> Column: 26 >>> Source Code:<font face="Arial" size=2> >> >> Must be a different response, since that source does not exist in the >> response above. > > Right. > >> >>> This error is followed by this error: >> >>> Error: xmlDoc.getElementsByTagName("returnvalue")[0] is undefined >>> Source File: >>> http://www.blah.com.au/Host/scorm1.2api.asp?loadURL=SCORM_courses/tp/... >> >>> Line: 161 >> >>> I can see how if the XML was not well formed why the error would occur >>> but not why the response doesn't appear to me to contain >>> "<font face="Arial" size=2>" >> >> Something is not right, but I can't tell what. The document returned >> parses correctly, so it is odd that `getElementsByTagName` cannot find >> the element, but there is a lot of context missing. Funnily enough, a call to the LMS that causes no error is supposed to return "". Which is what the XML appears to be doing. Now my guess is that xmlDoc is referencing a different/wrong response. > Clearly the client-side exception was not dealing with the quoted XML. I've given all the data on the errors that firebug and charles have provided. Unfortunately I can't give access to the LMS. I've started a ticket with the LMS vendor's support so maybe they can tell what's up? At any rate I've gotten enough info to allow the client to let me breathe. Andrew Poulos
From: Richard Cornford on 26 Jul 2010 03:15 Andrew Poulos wrote: <snip> > Now my guess is that xmlDoc is referencing a different/wrong > response. <snip> A mechanism that will do substitution (and particularly in response to HTTP 500 responses) does exist in IE/Windows. Look at "Internet Options" -> "Advanced" (tab) -> "Settings" -> "Browsing"(section, near the end) -> "Show friendly HTTP messages". If you find that "Show friendly HTTP messages" item is checked then uncheck it and see if you can re-create the error. (Probably having re-started IE, if not the OS) Of course it is still odd for the client-side code to be attempting to process a response body that has an HTTP 500 status. Richard.
From: jemptymethod on 26 Jul 2010 15:26 On Jul 24, 8:19 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: > On 25/07/2010 8:56 AM, David Mark wrote: > > All the while the onus was on me Of course it is. You have to incontrovertibly prove the issue emanates from 3rd party code. I sympathize but at the same time advise you to accept this state of affairs, its just the way it is. Sure railing against the universe occasionally feels good, but doing so too much can be counterproductive. A sincere good luck to you ....
From: Stefan Weiss on 26 Jul 2010 16:59
On 26/07/10 09:15, Richard Cornford wrote: > Of course it is still odd for the client-side code to be attempting to > process a response body that has an HTTP 500 status. I don't think it's that odd. I remember working on a project where the JS client code was communicating with Java web services (using SOAP) which would quite often return XML error documents with HTTP status 500. These documents contained the error description, so in order to show something useful to the user, they had to be processed by the client: <?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="..." xmlns:xsd="..." xmlns:xsi="..."> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server.userException</faultcode> <faultstring>(human readable error description here)</faultstring> <details>(scary looking stack trace, not shown to the user)</details> ..... The client side code would try to avoid sending invalid requests to the server as far as possible, but there were cases where input validation could only be performed on the server. A server-side validation failure would result in one of these error responses. IIRC, Apache Axis2 was used to send and receive the SOAP messages. One problem with these responses was that (xhr).responseXML.documentElement would be empty in Opera 9.x if the response status was not in the range [200,299]. We never managed to solve this problem, and so the only person on the project who used Opera would see vague generic error messages instead. Fortunately, that person was me ;) Axis2 is widely used in connection with web services, so I would guess that parsing the contents of a 500 response is actually not such a rare occurence. -- stefan |