No errors occur. The status code says "OK".
I'm thinking this API call isn't supposed to access the AWS data, it's just supposed to return a URL string, so un-initialized memory would be an odd problem for this call I would imagine.
What I'm expecting this call to return is Json like this:
{
"code": 200,
"status": "OK",
"data": {
"URL": "<URL HERE>"
},
"CallBackTimeMS": 224
}
Does this reproduce when you make the call from Postman? Can you provide us with the Title ID you're using for this, and is it okay if we create a player account in that title to test it? Oh, and is "Test" the only Key you're seeing this with, or do you see it for any Client call to this API method?
It seems to be working fine when using Postman. I seem to be seeing this with only API client calls to this particular API call url as I haven't tried any other urls using this method (I just need this last API call to work to get my manager app working. All other calls will be through unity using classes from PlayFab)
I'll just send a private email with the VS project files for my manager app if that's okay.
Sorry, but this is going to go much faster if we work with you on testing the issue on your side, as we're not really set up to dig into the code base for all developers. We do have support contracts for developers who need more hands-on work with us, but I wouldn't recommend going that route for a single issue.
In this case, we know that the call is working from Postman, and in our own SDK testing. Since all calls operate exactly the same way on the back-end (the SDKs, for example, just wrap the Web API calls), for a given set of inputs the returned data will be the same. So given that you're seeing the correct data in a call to Postman, and that you're getting a 200 (success) in the response, that means the data is coming back from the service the same way for your Forms version. So there has to be an issue with how the data is being parsed in the client code somewhere.
And looking at this again, could you try removing the gzip/deflate Accept-Encoding? I suspect that what we're seeing is that the StreamReader isn't correctly handling decompression, and the GetContentList call just looks normal because it's below the threshold length for Zip to have done anything with it (below a certain size, Zip is inefficient, so most libraries will just leave the submitted bytes alone).
No one has followed this question yet.