Entity: line 1: parser error : Start tag expected, '<' not found 
{"code ... 
^
[ERROR] Error Domain=com.google.GDataXML ... TiDOMDocumentProxy.m:48)

21 Answers

• Jeff, there may be a syntax error in your code somewhere that the parser can recover from. You will need to provide some code in order to give you accurate advice.

•    var xhr = Titanium.Network.createHTTPClient();
      xhr.onload = function() {
          alert(this.responseText);
          alert(this.responseXML);  // This line causes an exception
      };
      xhr.open("GET","<hidden>/getDefaultDeparture.html");
      xhr.send(data);
  

  response

  {"cityLocation":{"cityLocationName":"Dallas-Fort Worth, TX",
  "code":"DFW","countryCode":"US","countryName":
  "United States","latitude":32.9,"longitude":
  -97.0366666666667,"name":
  "Dallas-Fort Worth","rank":8,"state":"TX","stateName":"Texas"}}
  

• try adding this

  var xhr = Titanium.Network.createHTTPClient();
  xhr.onload = function() {
     alert(this.responseText);
  };
  xhr.open("GET","<hidden>/getDefaultDeparture.html");
  
  // set the request header
  xhr.setRequestHeader('Content-Type', 'application/json; charset=utf-8');
  
  xhr.send(data);
  

• Jeff

  The actual JSON data, as you have pasted it, is well-formed and so won't be causing the issue.

  The "Start tag expected <" message seems to imply that the parser is expecting html or xml from the server, would may be caused by the server sending a "text/html" or similar response.

  You could try setting the request header to "application/json" using xhr.setRequestHeader(), but if the server is not configured appropriately, you won't have any control over its response.

• ping Jeff - see my latest comment, which may help you resolve the issue. Please let me know if it doesn't, or mark the answer as correct so that I can see that it worked, and other people with the same problem can find it in future.

• Jeff, by putting Ti.API.info() messages around different parts of your code, can you isolate precisely which command is returning the error? If so, would you post the information here? Thanks

• Jeff

  I'd really like to help you get to the bottom of this issue, as other people are also having it. Would you please isolate the Titanium command that generates the error, and then I can see if it can be resolved.

• Jeff, are you using JSON.parse somewhere in your code? If so, you should remove it, because your data is accessible directly from this.responseText. Thus, this.responseText.cityLocation.stateName will return "Texas".

  Sorry it took some time, but I hope you find it useful anyway.

• I have just started getting the same bloody error. Even if I comment out everything that has anything to do with the returned data…

  Entity: line 2: parser error : Start tag expected, '<' not found
  {"LIST":"study_id,STUDY_ID_DICOM,STUDY_UID,ACCESSION_NUMBER,STUDY_DATETIME,STUDY
  ^
  [ERROR] Error Domain=com.google.GDataXML Code=-1 "The operation couldn’t be completed. (com.google.GDataXML error -1.)". in -[TiDOMDocumentProxy parseString:] (TiDOMDocumentProxy.m:50)
  

  It is the same JSON that I pull into another XCode project I have… no errors there…

• Experiencing same issue. Only change has been upgrade of Titanium from 1.4.2 r8e708e78 to nightly build 1.5.0 r6705da89, nothing else. Will post a ticket as this is a bug.

  Unfortunately, things with httpclient are currently much more serious than this which is discouraging. The client has become unusable for any serious development work with accumulation of issues over past months:

  setRequestHeaders appears broken again which is at second or third regression of same issue #1983. getResponseHeaders is broken #1502 in iOS which goes back 7 months ago with #519. You need to be able to at least transport JSON and work with an authentication mechanism for most web services work. You can also forget about passing credentials in url #2149. At this point you can transport JSON with ERRORS or possibly XML data without any form of authentication or correct headers. I am not sure what sort of unit testing is occurring. Bug reports and ticket filing from users should not be first line of communication that state of the client has deteriorated to this extent.

• Update: ticket #519 and #1502 have now been resolved so getResponseHeaders and setRequestHeaders are working the way they should. Passing credentials in url as user:pw is still broken and this particular problem with JSON persists on build from master. The emission of the XML parsing error occurs despite setting an "Accept" header to "application/json". Ticket #2480 filed for this issue. It not possible to work around this at present with proper error handling in httpclient code making this a serious bug.

• You can prevent the error from happening by making sure you never access the responseXML value, any access to responseXML when the response is json and the content type is set to text/html will cause this exception.

• To clarify the current issue, access to responseText results in XML error. This is NOT access to reponseXML. As an example, the following will generate the error as of 1.5.0 master last night.

  var request = Titanium.Network.createHTTPClient({
  
      onload:function(e) { 
          // check to see what we are getting
          Titanium.API.info('Loaded! Status: ' + this.status);
          Titanium.API.info('Response Header: ' + this.getResponseHeader('Content-Type'));
          Titanium.API.info('Response Text: ' + this.responseText);
  
          // check to see if response can be parsed despite XML error thrown
          try {
              json = JSON.parse(this.responseText);
              Titanium.API.info('JSON parsed from raw response: ' +  json);
          } catch (parse_error) {
              Titanium.API.error('JSON parse error from raw response: ' +  parse_error.message);
          }   
  
          // code to handle JSON response if successful - everything above this line to evaluate response
          if (request.status != 200 && request.status != 201) {
              request.onerror(e);
              return;
          } else {
              try {
                  json = JSON.parse(this.responseText);
              } catch (parse_error) {
                  Titanium.API.error('JSON parse error: ' +  parse_error.message);
              }
          }        
      },
      onerror:function(e) {
          label.text = "Got Error: "+ e.error;
          Titanium.API.info("Got Error: "+ e.error);
      }
  });
  request.open('GET', url, true);
  request.setRequestHeader('Accept', 'application/json');
  request.send();
  

• @fairwinds - I have a simpler case with this error too.
  I simply try to get a location of a redirected url with 302.
  I don't even access any response.

  The same xml parsing error comes up.

  I spoke with the appcelerator guys and they say it might be something in the header that confuses the httpclient.
  Anyway it's still wrong so I simply use the httpclient classes from an older build.

  Here is my post

  http://developer.appcelerator.com/question/84881/httpclient-broken-for-150–githash1dd0106

• @Tamas - Appreciate that you have isolated last working client. Btw, what was date of that? I will update ticket with this information. If this was known by appcelerator personnel, why was a ticket not created at this time? It is a very serious problem. Shouldn't have to resort to blending files from a release to get a working httpclient. In last few days I have attempted to communicate how crippled the client has become for development - pretty much unusable. Fortunately, a couple of issues have been resolved with some authentication issues still to work out, but this is a major show stopper to development. I did not get into the Cookie issues with them for which I believe there are at least two or three outstanding tickets.

• I'm using the files:

  TiNetworkHTTPClientResultProxy.m
  TiNetworkHTTPClientProxy.m

  from 06 Nov 2010 build.

  As for the ticket donno what to say, the appcelerator guys asked me to be sure is not the headers of the url I call that breaks the httpClient, and I didn't had too much time to investigate.

• @Tamas - Thanks. It would have been pretty difficult to assess within your app since getResponseHeaders has been broken for seven months and only repaired yesterday. At least with master right now you can see what you are getting back from your redirect. You can use curl -v to quickly get an answer about what you are getting in your response in any case but we needed a working getResponseHeaders.

  Looks like Steven Tramer is to blame for issue. There were a few commits Nov 9, 10 after which Jeff Hanie attempted a fix of this very issue on Nov 22 so was recognized at that time. Jeff's fix was to examine Content-Type in header to differentiate however I am able to verify that Content-Type in response is application/json.

• well I do this:

  httpclient->www.example.com/index.php
  

  but the server redirects me to

  www.example.com/index.php?blah=foo
  

  and I need the blah var.
  The old httpclient populates the location property just fine.

  The new one is not.

• Tamas. I dropped some older files from Oct 20 into my SDK to get some work done in interim. Issue has been on trunk from Nov 9 forward it appears. httpclient in 1.5.0 is unusable in iOS until this is prioritized and fixed.

  This has made me question what sort of testing is done by folks working on the SDK sources prior to committing to trunk and upon which I am building. Obviously, as any Ti developer working from trunk, one assumes more risks than working with release. Despite this, many projects prohibit changes to sources without first providing or writing tests and verifying work before it is added or merged to trunk. Don't really know what is happening with appcelerator as far as a process to prevent such occurrences. Thought appcelerator also had a qa personnel in addition to core developers. I know they are growing fast, but the product and value to developers is the SDK - something they seem to be committed to getting right.

  By all accounts this has been a problem for a few weeks on the trunk.

  You'd probably want to know what you are getting in response in any case. You can check with
  curl -vX GET www.example.com/index.php?blah=foo

• What can I say, sometimes is frustrating, but I must admit I'm all on the guys' side.
  Their work helped me a lot so I do whatever I can to help them back.
  One way is participating on this QA ( good or bad as it is).

  The same with the code.
  Httpclient is one of the issues. If we can use an older version that works, fine, problem solved( at least for the moment)
  I'm sure they will fix it in the end.
  Testing is hard, especially when you are the coder. How many times did we released a code that was not fully working( even we thought it does )? To many…

• True enough, this isn't about making things difficult, just getting things working and usable. I think we are all appreciative of the framework and what is getting accomplished in the long haul. That said appcelerator is a developing company and I am sure there will be more stability and refinement as things mature.