I'm not sure, but I have just a general observation. If you're sending this as a HTTP POST with the content type of application/x-www-form-urlencoded the Configuration data has +'s in it that will most likely get parsed to spaces by the receiving server.
I would verify that the configuration file is correct before you base64-encode it. It is a long time since I looked at all this but I vaguely remember encountering unexpected problems with the XML header - particularly to do with a need to use utf-8
not utf-16. This is all very vague so my apologies if I'm pointing you in the wrong direction.
I left a few additional suggestions on your StackOverflow post, but my main idea was to check if you are getting a requestId back in the call. If so, your request is valid to the API and the failure is at a higher level. The API will hand you
back a x-ms-requestid header back, which you can toss to GetOperationStatus on the API and Azure will tell you why its mad at the request.
If you aren't getting that requestId back, the request itself is being dumped by the API before processing, which would be more of a data-contract-mismatch problem and you should make sure you are sending valid everything even to the extend of passing a
valid base64 string that is not a valid config (just to ensure the API accepts the message)
To debug, copy the CSCONF and CSDEF into a real Visual Studio Azure project. You will get an error:
The 'name' attribute is invalid - The value '' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:NamedElementNameString' - The Pattern constraint failed.c:\dev\Blog\myProjName\myProjName\ServiceDefinition.csdef226
The XML specification is not valid: The 'name' attribute is invalid - The value '' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:NamedElementNameString' - The Pattern constraint failed.c:\dev\Blog\myProjName\myProjName\ServiceDefinition.csdef220
This is almost a stupid question, but I'll suggest it anyways:
Have you tried omitting the XML Declaration from the POST body?
I took your request and resent it via a wrapper class I have to a test role of my own. The only difference b/t your's and the working one for me is that the XML declaration is absent in the working request (since it can be derived from the
Maarten, believe it or not, I'm pretty sure the issue is that you're missing a slash at the end of your URL.
It should be: /<subscription-id>/services/hostedservices/phptest1/deploymentslots/production/?comp=config
I just tried dropping the slash, and I get the same error about the invalid request. I believe without that slash, the Service Management API is treating the request as a Create Deployment request (with a bogus but maybe ignored query string).
Just tried: I don't actually have to. Although in some cases PHP's base64_encode') is not giving the exact same string as .NET does and therefore fails. Seems to be due to \r\n and UTF8. Will keep the newline replacements in there untill I figure out the
exact cause why this does not work for any XML configuration. Thanks for the support!