When the REST component downloads a file, it checks the content-type and tries to parse it. For the content-type detection it simply checks if the provided content-type is exactly 'text/xml' or 'application/xml' for XML and anything else for text-based/unparsed. Problem is: this only works when the server sends exactly one of these two strings as content-type and nothing else.
When it tries to download 'http://packages.zendframework.com/rest/p/zend_http/info.xml' the given content-type sent by the server is (currently) 'text/html; charset=iso-8859-1,text/xml', which does not match one of the strings above and gets wrongly interpreted as text and not parsed to an XML object. These are two valid content-types of which the client (pyrus) can choose what to use and it should be able to detect that it can be used as XML data.
The exact position of the problematic code is (currently) in '/Pyrus/REST.php' on lines 117-133 (in method 'retrieveData'). The particular code that is triggering the errors (In /Pyrus/Channel/RemotePackage.php) fails because it expects an XML object (line 450: "$info = $this->getPackageInfo($var);") and instead gets a string and triggers errors like 'Invalid string offset' (lines 486-490, all like "$pxml->channel = $info['c'];").
There are two Solutions to this that i currently see:
1) Implement a more dynamic parser that can parse such complex content-types like above.
2) An optional parameter to the 'retrieveData' method that allows the caller to enforce a specific parser to be used regardless of what the server sends. This would be easier to implement then a dynamic parser (although one would be a good thing anyway) and still solves the error. The drawback of this solution is that every (problematic) call to the method above needs to be touched for it to be fixed. The advantage is that if it gets implemented like this, it is pretty robust.
[I could even do this myself if nobody has time for this, but first i want to make sure that the patch would be accepted and i might need some time fiddling myself into git and how to develop for pyrus.]
When the REST component downloads a file, it checks the content-type and tries to parse it. For the content-type detection it simply checks if the provided content-type is exactly 'text/xml' or 'application/xml' for XML and anything else for text-based/unparsed. Problem is: this only works when the server sends exactly one of these two strings as content-type and nothing else.
When it tries to download 'http://packages.zendframework.com/rest/p/zend_http/info.xml' the given content-type sent by the server is (currently) 'text/html; charset=iso-8859-1,text/xml', which does not match one of the strings above and gets wrongly interpreted as text and not parsed to an XML object. These are two valid content-types of which the client (pyrus) can choose what to use and it should be able to detect that it can be used as XML data.
The exact position of the problematic code is (currently) in '/Pyrus/REST.php' on lines 117-133 (in method 'retrieveData'). The particular code that is triggering the errors (In /Pyrus/Channel/RemotePackage.php) fails because it expects an XML object (line 450: "$info = $this->getPackageInfo($var);") and instead gets a string and triggers errors like 'Invalid string offset' (lines 486-490, all like "$pxml->channel = $info['c'];").
There are two Solutions to this that i currently see:
1) Implement a more dynamic parser that can parse such complex content-types like above.
2) An optional parameter to the 'retrieveData' method that allows the caller to enforce a specific parser to be used regardless of what the server sends. This would be easier to implement then a dynamic parser (although one would be a good thing anyway) and still solves the error. The drawback of this solution is that every (problematic) call to the method above needs to be touched for it to be fixed. The advantage is that if it gets implemented like this, it is pretty robust.
[I could even do this myself if nobody has time for this, but first i want to make sure that the patch would be accepted and i might need some time fiddling myself into git and how to develop for pyrus.]