Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
SendHTTPRequest and zip files
We have a function where we are uploading files to be temporarily stored on an Azure Blob. We're not doing this directly but rather going through a third party web service. As such we have utilised the HTTPClientServices SendHTTPRequest service.
It works if I send text files but doesn't yet work with pdf's, images or zip files.
After much testing I'm inclined to believe the issue is with the web service itself as it returns a successful status but what ends up in the blob is not what is being sent. The file is corrupted somewhere along the line. I'm having them investigate this but in the meantime, I thought it pertinent to ask, is it reasonable to expect this to work with zip files?
Use case we're aiming for is to zip up a number (any number) of files, mostly images but could be others and upload the zip to the blob, then send an email to the appropriate person with a link to download the file. Can anyone foresee any issues with this concept that I may have not considered?
Thanks
It works if I send text files but doesn't yet work with pdf's, images or zip files.
After much testing I'm inclined to believe the issue is with the web service itself as it returns a successful status but what ends up in the blob is not what is being sent. The file is corrupted somewhere along the line. I'm having them investigate this but in the meantime, I thought it pertinent to ask, is it reasonable to expect this to work with zip files?
Use case we're aiming for is to zip up a number (any number) of files, mostly images but could be others and upload the zip to the blob, then send an email to the appropriate person with a link to download the file. Can anyone foresee any issues with this concept that I may have not considered?
Thanks
Comments
Initially, it was rejecting as a bad request. This turned out to be because of the content-type header. They corrected their documentation. I corrected the code and no more rejections, but only text files make it all the way intact.
So I think it's very likely they need to make some tweaks to accept all file types but never hurts to check my own backyard
It worked with a png.
More testing on my end I guess
I've since tried replicating the same headers that Postman created just in case there was something in that but no luck.
The other guys have arranged to leave a copy of the file they receive on a server I can access. More testing reveals they aren't receiving the correct file so there's an issue with the send. If I send anything other than a text file, they end up with a 1kb file that can't be opened.
Is the use of getByteSize() an appropriate means of retrieving the correct value for adding to the "Content-Length" header or should I be doing something else?
Upon recommendation, I've just installed Fiddler Everywhere to see if I can capture what's happening. It doesn't capture the activity when I send it from OI. It does capture it when I make the request out of Postman. That's probably a setting in Fiddler Everywhere but it may provide a clue.
The other thing I got out of that is that I can check the contents of what's being sent with a successful request from Postman. A look at the body and it appears that the end result of the successful attempts may just be the first line of the body.
Sample of what should be going
Sample of what is received on an unsuccessful attempt if I open it in notepad.
I'm sure there's a way to configure it to pick up what I'm sending because I have used wireshark for that purpose before. I'm just a little reluctant to use wireshark because I remember two things.
1. It was, let's say, less than intuitive to figure out what needed to be set and
2. I then had issues with several of my standard network connections.
I thought I had uninstalled wireshark because of the trouble it had caused but no it's still here. Possibly just uninstalled a component.
Now it's just a case of deciphering what the results are telling me.
When I send using Postman, a whole lot of stuff is happening.
When I send out of OI, it looks like only one packet is being sent.
I think fresh eyes tomorrow might be best.
If I base64 encode the body of the request, the whole thing (or at least it appears to be the whole thing) makes it.
Something about sending the raw binary data is terminating the process.
That's not the case here.
What our client wants is to send copies of files to their client based on a report. As their could be any number of files, even zipping them is likely to be far too large to email directly. So, we're zipping and uploading them to a Blob and sending an email with a link to download. If we base64 encode it, we can get it up there but when they download it, they can't do anything with it.
Unless of course you're going to say "oh that's easy, just do this..."
When you say you are "zipping and uploading them to a Blob", is the "uploading" part being handled by the Web API? I'm tempted to say that FTP is a better fit.
It's simple and allows us to specify a timeframe after which the files will be deleted so I don't mind it, other than this one issue where I can't get the files I want to make it. That's a bummer.