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

Comments

  • I think this should work, but I honestly can't say I've done this. Did their web service provide specific instructions on how the request should be configured?
  • They did but they wrote it specifically for this purpose so it hasn't been "proven" as yet.
    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
  • I suggest using a tool like Postman to send the .zip file to rule out any problems with HTTPClient_Services.
  • Fair point and bugger!
    It worked with a png.

    More testing on my end I guess
  • So the PNG file worked but the ZIP file didn't via SendHTTPRequest?
  • No. The png worked using postman but didn't via SendHTTPRequest.
    I've since tried replicating the same headers that Postman created just in case there was something in that but no luck.
  • Definitely my backyard so my problem to fix.
    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?
  • I think getByteSize() should work fine. However, Content-Length is not a requirement for the full payload to be received. It is meta-data that may or may not be used by the server to truncate the body after it is received. I'm inclined to think that something else is going on. I've been trying to duplicate your situation and I'm experiencing similar results. I've been able to get more data to come through by setting the Content-Type to application/octet-stream, but the content on the other end is not the same that I sent it. I think it needs to be converted. I'll keep looking into this on my end as I'm interested to know how this can work.
  • I was using application/octet-stream and text files worked. I thought that might have been the problem but changing it to something more specific for the the other files like "image/png" for a png didn't change the result.

    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.

  • have you tried wireshark?
  • Same non result with wireshark.
    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.
  • ok, my experience with wire shark has been positive. Assuming you are not using https, you should be able to see everything.
  • Well @josh, you'll be happy to hear I got Wireshark to work.

    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.
  • One more tidbit that might spark an idea in those smarter than I.
    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.
  • I was going to ask if Base64 was acceptable for your project. We've always been successful using that.
  • Unless I'm mistaken, Base64 can only work if the end recipient has a means of decoding it?
    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..."


  • No, you are correct. They would need a way to decode it. However, decoding libraries are pretty standard.

    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.
  • The Azure component is managed by the client's IT firm. We asked for a means of uploading files to it. They provided the API. We work with the tools we're given.
    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.
Sign In or Register to comment.