Download media object in PHPRETS - php

Question

Background Information
I want to download photos of a specific property using PHPRETS.
My PHPRETS configuration works successfully for downloading property data. The problem is only with downloading media files.
I am able to download photos of the property using RETS Connector, the Windows application, meaning the images exist.
The value that I pass as the object key (N3273704) is the value that I've got from the KeyField (ml_num)
KeyField
ml_num
The code I run
$photos = $rets->GetObject("Property", "Photo", "N3273704", "*", 0);
var_dump($photos);
foreach ($photos as $photo) {
$listing = $photo['Content-ID'];
$number = $photo['Object-ID'];
if ($photo['Success'] == true) {
file_put_contents("image-{$listing}-{$number}.jpg", $photo['Data']);
} else {
echo "({$listing}-{$number}): {$photo['ReplyCode']} = {$photo['ReplyText']}\n";
}
}
Raw header and response
[2015-07-29 13:16:09] PHRETS.DEBUG: Sending HTTP Request for http://rets.torontomls.net:6103/rets-treb3pv/server/getobject (GetObject) {"query":{"Resource":"Property","Type":"Photo","ID":"N3273704:*","Location":0},"headers":{"User-Agent":"PHRETS/2.0","RETS-Version":"RETS/1.5","Accept-Encoding":"gzip"},"cookies": ..."]} []
[2015-07-29 13:16:09] PHRETS.DEBUG: Response: HTTP 200 [] []
Output on screen (result of var_dump)
array(20) {
[0]=>
object(PHRETS\Models\Object)#32 (10) {
["content_type":protected]=>
string(8) "text/xml"
["content_id":protected]=>
string(4) "null"
["object_id":protected]=>
string(4) "null"
["mime_version":protected]=>
NULL
["location":protected]=>
NULL
["content_description":protected]=>
NULL
["content_sub_description":protected]=>
NULL
["content":protected]=>
string(192) "<?xml version="1.0" standalone="no"?>
<!DOCTYPE RETS SYSTEM "RETS-20041001.dtd">
<RETS ReplyCode="20403" ReplyText="No Object Found: No matching object was found to satisfy the request."/>"
["preferred":protected]=>
NULL
["error":protected]=>
object(PHRETS\Models\RETSError)#45 (2) {
["code":protected]=>
int(20403)
["message":protected]=>
string(69) "No Object Found: No matching object was found to satisfy the request."
}
}
[1]=> ...

Answer 1

I was able to figure out the issue and I'm writing this in the hope it saves somebody's time.
After monitoring HTTP traffic and comparing raw headers sent from PHRETS and RETS connector, the Windows application, it turned out that some RETS servers (in this case, Toronto Real Estate Board) require the "Accept" field to be present in the header. So, the problem is solved by adding the following line to the constructor of Session class:
'Accept' => '*/*',

Answer 2

I wanted to contribute one note... TREB has the KeyField misconfigured. They are using the DBName version of the Property's identifying field (ml_num), whereas the KeyField is supposed to be the SystemName version of that field (Ml_num).... just a matter of difference in case, but enough to be a breaking change for RETS clients that would derive the KeyField automatically from the RETS metadata.