This is a serious problem. Code samples sent to Thomas Huelbert\nearlier today to demonstrate. JSON response is being interpreted as\nXML despite fact we are obtaining responseText from client and not\nresponseXML.
\n\"Accept\" header in code set to \"application/json\". With recent\nfixes #519 and #1502, responseHeaders verifies response\nreceived is application/json.
\nAll JSON responses received with following error
\nEntity: line 1: parser error : Start tag expected, '<' not\nfound
\n[ERROR] Error Domain=com.google.GDataXML\nCode=-1 \"The operation couldn’t be completed.\n(com.google.GDataXML error -1.)\". in -TiDOMDocumentProxy\nparseString:
\nIt is possible to parse the response without error checking but\nnot possible to work around this with proper error handling.
Note that most recent tests using Dec 1 2010 18:59 r44a760a9\nnightly
According to another developer on Q&A, the last working\nhttpclient in 1.5.0 without parsing error has githash of 3ee6a97\nwho has another simple use case to demonstrate issue at \nhttp://developer.appcelerator.com/question/84881/httpclient-broken-....
Looks like Steven Tramer is to blame for issue in result proxy.\nThere were a few commits Nov 9, 10 after which Jeff Hanie attempted\na fix of this very issue on Nov 22 so it was recognized at that\ntime but fix is apparently not adequate. Jeff's fix was to examine\nContent-Type in header to differentiate however I am able to verify\nthat Content-Type in response is application/json.
\n\n @try {\n value = [delegate valueForKey:key];\n if ([key isEqual:@\"responseXML\"])\n {\n // check response content-type before trying to parse into XML - gets rid\n // of the silent XML parse error when not XML content\n id ct = [delegate getResponseHeader:[NSArray arrayWithObject:@\"Content-Type\"]];\n if ([ct rangeOfString:@\"xml\"].location==NSNotFound)\n {\n return;\n }\n }\n }\nsending for triage
Odd. That code checks for \"responseXML\" which MUST be valid XML,\nnot 'responseText', which can be any old text. What is the sample\ncode for this? To get a proper fix, it'd be necessary to test\nagainst the actual server, or at very least, the expected result\nfrom the server as to work with the real data.
Blain. Exactly. I have sent Thomas complete sample apps and in\naddition to link for couchDBX that you can use to test. No xml\nthere, JSON request and responses only. The code and server tests\nthat I spend a good amount of time detailing for you can all be run\nwithin 15 mins, Please let me know if you would like me to send it\ndirectly to you. Need your email address to do so.
Blain. The info I sent Thomas also contains curl comparisons\nmade against the server. This was one of a few issues I brought\nforward concerning httpclient including getResponseHeaders that was\nrecently fixed. There are others outstanding including this one,\nwhich is the most serious that is a show stopper for any web\nservices work with JSON. I am using pre Nov 9 httpclient files with\n1.5.0 nightly build in order to continue my own development without\nthe issue.
I'm the author of the post \nhttp://developer.appcelerator.com/question/84881/httpclient-broken-...
\nThe last commit that suppress the responseXML parse errors still\ngives error in some cases:
\nI simply call a link that makes a redirect with a 302, and try\nto get the new location and nothing more (so no parsing for any\nkind of response).
\nThe headers the server sends seems to be ok to me, but the\nlocation never gets populated.
\nThe older commit githash=3ee6a97 works just fine.
\nHere are the headers:
\nTamas-Daniels-MacBook-Pro:~ Spawn$ curl -vvv http://www.motorsport-total.com/f1/live/htdocs/ticker.php
\nAbout to connect() to www.motorsport-total.com port\n80 (#0) Trying 87.119.204.100... connected * Connected to\nwww.motorsport-total.com\n(87.119.204.100) port 80 (#0)
\nGET /f1/live/htdocs/ticker.php HTTP/1.1 User-Agent: curl/7.19.7\n(universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l\nzlib/1.2.3 Host: www.motorsport-total.com\nAccept: /
\n< HTTP/1.1 302 Found
\n
\n< Date: Wed, 08 Dec 2010 21:01:02 GMT
\n< Server: Apache/2.0.52 (CentOS)
\n< Set-Cookie: f1totaluser=q67sgsc5fcouj6vp9j47d1bn80; path=/
\n< Expires: Thu, 19 Nov 1981 08:52:00 GMT
\n< Cache-Control: no-store, no-cache, must-revalidate,\npost-check=0, pre-check=0
\n< Pragma: no-cache
\n< Location: \nhttp://www.motorsport-total.com/f1/live/htdocs/ticker.php?strecken_...
\n< Content-Length: 0
\n< Connection: close
\n< Content-Type: text/html; charset=iso-8859-1
\n<
\n* Closing connection #0
I think I found the issue
\nin TiNetworkHTTPClientProxy.m you are releasing to nil the request\nafter it finishes.
\n\n-(void)requestFinished:(ASIHTTPRequest *)request_\n{\n [self _fireReadyStateChange:NetworkClientStateDone];\n if (connected)\n {\n connected = NO;\n [[TiApp app] stopNetwork];\n }\n RELEASE_TO_NIL(request);\n}\n\nI commented the RELEASE_TO_NIL(request); line\nand location is back in place
Blain - This issue was repaired two days ago by Steven Tramer\nwho fixed his original work that caused the problem. Why has this\nticket not been updated?
\nNoting for others that response codes have recently been changed\nto text from integers.
\nI believe this issue ought to have been categorized as a high\npriority. The client is such an important component to the SDK and\nwhen issues like this arise, it is impossible to carry on\nproductive development (as opposed to a UI bug that you can afford\nto work around or wait until fixed).
Still missing from the ticket is any sample code to fully\nrecreate the issue and more importantly, verify any impact beyond a\nfalse warning that is safely contained within a try/catch\nstructure.
Is there any example JS to better illustrate the impact beyond\nthe spurious warning? This may be like the 4.1 issue where there\nwas a warning about missing symbols that did not have any actual\nimpact on performance.
Blain. Comprehensive documentation of the issue including three\nsample apps had been sent to Thomas Huelbert almost two weeks ago.\nHe advised he would ensure it would be forwarded to whomever was\nassigned the issue. This is noted in the first paragraph when\nticket was filed. I spent significant time writing this up. This\nwas followed up with detailed information with what was broken,\nwhen it occurred and who was to blame. Please see Thomas for the\ninfo which was emailed to him Dec 1.
\nSeeing this sort of request for additional information almost\ntwo weeks afterwards does not illicit good feelings since you are\nlate to the party. Steven Tramer modified the code about 4 days\nago. Issue cannot be duplicated since the issue has since been\nresolved.
\nThis was a high priority item with a release immanent. Thomas\nreceived the information but was not responsible for the ticket.\nSteven did the work (possibly with or without the information) and\nalmost two weeks later, you want more information after it has been\nfixed with notations in the repository. So far as I am concerned, I\nwould have expected Steven to communicate on the ticket. For most\nprojects, the repository and tickets system are the primary means\nof developers communication and not stepping on each other's toes.\nI sincerely want to help you folks and possibly contribute bug\nfixes in future however this sort of experience can't help.
Blain,
\nHere is the issue with the location - build 1.5.1 9819ce0\n13/12/2010
\n\nvar xhr = Titanium.Network.createHTTPClient();\n\nxhr.onload = function(e){\n Ti.API.info('onload');\n Ti.API.info(xhr.location);\n // Ti.API.info(xhr.responseText);\n};\n\nxhr.onerror = function(e){\n Ti.API.info('onerror');\n // Ti.API.info(xhr.responseText);\n};\n\nxhr.open('GET','http://www.motorsport-total.com/f1/live/htdocs/ticker.php');\nxhr.send();\n\nThe result is:
\n\n[INFO] test/1.0 (1.5.1_9819ce0_13122010.9819ce0)\n[INFO] onload\n[INFO] <null>\n\nCommenting the
\n\n\nRELEASE_TO_NIL(request);\n\nline in TiNetworkHTTPClientProxy.m in\nfunction -(void)requestFinished:(ASIHTTPRequest\n*)request_
\nputs the location back in place
\n\n\n[INFO] test/1.0 (1.5.1_9819ce0_13122010.9819ce0)\n[INFO] onload\n[INFO] http://www.motorsport-total.com/f1/live/htdocs/ticker.php?strecken_id=19&event_id=7&kunde=default\nTamas, I think the issue with xhr.responseText is something\nelse. I've opened it as #2573. As mentioned on the bug, this is an\nknown compromise to stop memory issues caused by recursive XHR\nchains, and the workaround is to use 'this'.
Have tested from 1.5.1 continuous build and changes appear good.\nThere are two additional issues I have identified with iOS\nhttpclient but will file under separate tickets. So far as I am\nconcerned this ticket should be marked resolved.
Going to fixed-in-qa this due to lack of activity and the fact\nthat it seems to be a dupe of several bugs.
[INFO] Titanium SDK version: 1.6.0 (01/13/11\n08:11 7ca73a3)