[RESOLVED] SmugMug API 1.1.0 bug: smugmug.images.upload method returns incomplete XML
crenner
Registered Users Posts: 33 Big grins
I have found what I believe to be a bug in the SmugMug API version 1.1.0:
When I use the smugmug.images.upload method, an XML result like the following is returned to me:
[PHP]<?xml version='1.0' encoding="iso-8859-1" ?>
<methodResponse>
<rsp stat="ok">
<ImageID>97852912</ImageID>
</rsp>[/PHP](sorry for marking this as PHP code, but a regular CODE block was removing data)
Please note that the XML is incomplete because the "methodResponse" tag was never closed in the XML document. This is at the very least improper/incomplete XML, and is also probably a bug in the SmugMug API.
This causes the Microsoft XML parser to choke with the following error code and description:
parseError.errorCode = -1072896685
parseError.reason = "The following tags were not closed: methodResponse."
I am perfectly capable of manually parsing the text of the XML to get the ImageID, but that doesn't change the fact that there is a bug here.
This raises two questions:
1) Can this be fixed?
2) Is anyone else seeing this bug?
Thanks!
When I use the smugmug.images.upload method, an XML result like the following is returned to me:
[PHP]<?xml version='1.0' encoding="iso-8859-1" ?>
<methodResponse>
<rsp stat="ok">
<ImageID>97852912</ImageID>
</rsp>[/PHP](sorry for marking this as PHP code, but a regular CODE block was removing data)
Please note that the XML is incomplete because the "methodResponse" tag was never closed in the XML document. This is at the very least improper/incomplete XML, and is also probably a bug in the SmugMug API.
This causes the Microsoft XML parser to choke with the following error code and description:
parseError.errorCode = -1072896685
parseError.reason = "The following tags were not closed: methodResponse."
I am perfectly capable of manually parsing the text of the XML to get the ImageID, but that doesn't change the fact that there is a bug here.
This raises two questions:
1) Can this be fixed?
2) Is anyone else seeing this bug?
Thanks!
0
Comments
Cheers,
David
SmugMug API Developer
My Photos
OK. Due to the incomplete documentation, I'm not sure whether I'm using Upload via POST or smugmug.images.upload.
For the most part, I am using the SmugMug 1.1.0 REST API.
For image uploads, I just kept tinkering with it until it worked. I am uploading via POST, but I thought I was doing it with the smugmug.images.upload method. Maybe I'm wrong. Either way, I'm getting invalid XML returned to me.
Thanks for the feedback.
My two questions remain:
1) Can this be fixed?
2) Is anyone else exeriencing this bug?
I am working around the XML bug in basetosmug 0.1 Build 14 (Alpha) with a text-parsing hack that I threw together in a few minutes. I would prefer to use MSXML to parse the returned document, since it is already being used elsewhere in my product. Unfortunately, MSXML does not fix buggy XML. It just returns a parse error.
For the techies:
As far as whether I am using the smugmug.images.upload method or Upload via POST, you tell me:
- I am using VB6SP6 for my SmugAPI class.
- In my SmugAPI class, I have a method called UploadImage
- When SmugAPI.UploadImage is called is uses the following:
- http (not https)
- the HTTP POST method
- this location: upload.SmugMug.com/photos/xmladd.mg
- a request for a REST response
- Here is a sample call:
- This is sent as a HTTP POST with multipart MIME form encoding that contains the image itself as the POST data per the specs on http://www.smugmug.com/hack/xmlrpc-post
As far as whether I'm using smugmug.images.upload or Upload via POST, it's hard to tell, as I'm using the specs on the Upload via POST page for 95% of the requirements, including the URI, the POST method, and the encoding. But notice that my URI defines smugmug.images.upload as the method variable. So even though I appear to be using Upload via POST, I may be using smugmug.images.upload.I'm afraid to tamper with it too much, as this was one of the more difficult things for me to get working.
Anyway, my two questions remain (see above in red and bold). Thanks!
Try setting the ResponseType=XML-RPC and see if the result is any different.
Cheers,
David
SmugMug API Developer
My Photos
It does indeed appear to be a bug in the REST response ONLY. When I changed the response type to XML-RPC, this is an example of what I got:
[PHP]<?xml version='1.0' encoding="iso-8859-1" ?>
<methodResponse>
<params>
<param>
<value>
<int>98068242</int>
</value>
</param>
</params>
</methodResponse>
[/PHP]
Another example:
[PHP]<?xml version='1.0' encoding="iso-8859-1" ?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value>
<int>5</int>
</value>
</member>
<member>
<name>faultString</name>
<value>
<string>system error (galleryclosed)</string>
</value>
</member>
</struct>
</value>
</fault>
</methodResponse>
[/PHP]
At this point I can confirm that the bug I reported in the SmugMug API version 1.1.0 (for upload via POST) occurs ONLY when a ResponseType of REST is requested. (The methodResponse tag does not get closed)
While the XML returned by the ResponseType of XML-RPC is considerably different, it can be parsed by MSXML, because it is valid XML (all the tags are closed properly).
At this point, I have the current development version of my code correctly parsing the XML-RPC response, and I feel much better about it than the text-parsing hack I had thrown into my current release for the REST response.
While I do have a working solution, everyone should be at least aware that there is a confirmed incomplete XML bug in the response with the following conditions:
SmugMug API version 1.1.0- Upload via POST
- ResponseType=REST
Good catch. Fixed?
Don
Sorry for the slow response. Haven't sat down with my code in about a week.
Yes, it appears to be fixed.
Here is a REST response I received today:[PHP]<?xml version='1.0' encoding="iso-8859-1" ?>
<rsp stat="ok">
<ImageID>99513742</ImageID>
</rsp>[/PHP]
There are no longer any unclosed tags, and methodResponse is no longer part of the heirarchy of the response given.
In MSXML, doing a XPath-based search for Nodes that fit the search pattern "/rsp[@stat = 'ok']/ImageID", results in a single node with a .text property of 99513742.
This is the desired behavior.