OK, so this has kept me busy for too long. Testing the api
call with the SOAPUI or Restlett in Chrome I can get the expected result - a binary that represents a pdf
or possibly html
. I've highlighted the part of the Url in question in yellow (this does represent a document number that should be downloaded and in the parent system is "130318/HJRWIQ" but we cannot use the '/'
in the url thus the 130318%2FHJRWIQ representation of the same in the web-api call.
Chrome Restlett Api test results:
Now, trying to do the same in c# this url returns a '
404 not found
and I suspect that the %2F is somehow encoded back to a '/' again. Below is two different methods I tried (both doing the same) :
c# methods to download the same response;
internal static string DownloadData(string resourceUrl, string authorizationApi, StringBuilder sb)
{
using (var wc = new WebClient())
{
// copy data to byte[]
wc.Headers.Add("Content-Type", "application/pdf");
wc.Headers.Add("Authorization", authorizationApi);
wc.Headers.Add("OData-MaxVersion", "4.0");
wc.Headers.Add("OData-Version", "4.0");
var data = wc.DownloadData(new Uri(@resourceUrl));
sb.AppendLine(" url used\t" + wc.BaseAddress);
sb.AppendLine(" querystring value\t" + wc.Encoding);
return Convert.ToBase64String(data);
}
}
internal static string DownloadData(string resourceUrl, string authorizationApi, ITracingService trace)
{
try
{
using (var wc = new WebClient())
{
wc.Headers.Add("ContentType", " text/plain");
wc.Headers.Add("Authorization", authorizationApi);
//wc.Headers.Add("Content-Disposition", "attachment; filename='82400200813_-doc.pdf'");
//wc.Headers.Add("Transfer-Encoding", "chunked");
return wc.DownloadString(new Uri(@resourceUrl));
}
}
catch (Exception e)
{
trace.Trace("DOWNLOAD DATA EXCEPTION: \n" + e.Message + "\n" + e.InnerException);
}
return "";
}
The Exception logged as per above :
DOWNLOAD DATA EXCEPTION: The remote server returned an error: (404) Not Found.
just ignore the string builder and tracing (this is used to debug remotely) as this runs online.
Anyone else ran into this before ? How do I get the url
passed correctly ?
EDIT Even MS reproduced this and does not have a workaround answer - I moved this code to an azure service that could do the get independently and pass the result back;