As per the API documentation here I formed my request with postman as follows:
. This is working fine.
But when it comes to binary content(encoded in base64 format), it uploads the file but that is not previewed when I try to open the same on OneDrive.
File gets uploaded successfully but not previewable.
What am I missing here? Any suggestions?
OneDrive doesn't support Content-Transfer-Encoding when using the multi-part upload method. In this case, we're ignoring the header (that seems like a bug) and just storing the base64 encoded data in the file stream (without decoding it).
You'll have to upload the raw bytes as the second part of the request, without any content-transfer-encoding, to have this work.
Since it seems like you are just uploading a file and not trying to set any custom metadata while doing it, you're better off using one of the other upload methods, like PUT or createUploadSession
Drive does not store the image in the base64 format it stores it in binary. you can directly select the image using postman and can upload as binary with the multipart request
Here is the link for adding blob in the postman
How to upload images using postman to azure blob storage
Related
I'm trying to upload files from incoming e-mails to DevOps using the logic app's connector "HTTP request to Azure DevOps", to than attach them to a Work Item.
The flow works, but the files I attach results in base64 encoded form if I upload them in base64, and messed up binaries if I upload them in binary format.
Anyway, them are unusable.
Is there a way to correctly upload files to DevOps?
(docx, xlsx, pdf, images, and so on?)
I tried to upload files in base64 form and binary form with "HTTP request to Azure DevOps" but I can't get the file content correctly after the upload.
I'm expecting to download the correct file from the url property outputted from "HTTP request to Azure DevOps".
Solved putting
"Body": "#{binary(body('Get_Attachment_(V2)')?['contentBytes'])}"
as body :-)
The function to use is actually binary() and not base64().
however "Body is Base64" has to be set to true.
I am struggling to get file upload on google cloud storage working with flutter.
We are using a PUT signed URL generated via https://cloud.google.com/storage/docs/samples/storage-generate-upload-signed-url-v4#storage_generate_upload_signed_url_v4-nodejs
On the Flutter side, when we make PUT with a multipart form request it ends up with "No Content" and failed to upload the file. We are adding a file to the request. as a multipart form.
final httpImage = http.MultipartFile.fromBytes('file', bytes,
contentType: MediaType.parse("image/png"),
filename: fileName);
and certainly blocked now with the implementation. Already tried to get a binary array from the file and posting file along with the policy but that did not work either.
Hey so this might be a broad question, but I'm currently designing a REST api and I've currently been using multipart-form to upload files. The thing is that I would like to upload a file in a Patch request, which doesn't allow multipart data, but does allow the data to be uploaded in the body of the request. I would like to have one way to upload files to be standard in my API. Should I stick with multipart or would it be okay to just attach a base64 string with a mimetype in the body of my request? Would there be any limitations to the base64 method? I'm mostly planning to upload pictures no more than 3MB if that makes a difference.
I am using SoftLayer_Billing_Invoice::getPdfDetailed to retrieve the latest invoice, but the file does not seem to be a binary file. How to decode that file and get it opened.
that depends on if you are using a Softlayer client or if you are using simple REST request, using a simple REST request the response is encoded in base64 and you must decode it (you could try using this online tool http://www.motobit.com/util/base64-decoder-encoder.asp and export the result in a file)
Now if you are using a Sofltyer client such as Softlayer's Python or Ruby client they are using xmlrpc for the request and they uses its own data type to store that data you can see an example about that using the Python client here How to get "PDF" file from the binary data of SoftLayer's quote?
Regards
I have a Node.js server running on a Google Compute Engine virtual instance. The server streams incoming files to Google Cloud Storage GCS. My code is here: Node.js stream upload directly to Google Cloud Storage
I'm passing Content-Type in the XML headers and it's working just fine for image/jpeg MIME-types, but for video/mp4 GCS is writing files as application/octet-stream.
There's not much to this, so I'm totally at a loss for what could be wrong ... any ideas are welcome!
Update/Solution
The problem was due to the fact that the multiparty module was creating content-type: octet-stream headers on the 'part' object that I was passing into the pipe to GCS. This caused GCS to receive two content-types, of which the octet part was last. As a result, GCS was using this for the inbound file.
Ok, looking at your HTTP request and response it seems like content-type is specified in the URL returned as part of the initial HTTP request. The initial HTTP request should return the endpoint which can be used to upload the file. I'm not sure why that is specified there but looking at the documentation (https://developers.google.com/storage/docs/json_api/v1/how-tos/upload - start a resumable session) it says that X-Upload-Content-Type needs to be specified, along some other headers. This doesn't seem to be specified in HTTP requests that were mentioned above. There might be an issue with the library used but the returned endpoint does not look as what is specified in the documentation.
Have a look at https://developers.google.com/storage/docs/json_api/v1/how-tos/upload, "Example: Resumable session initiation request" and see if you still have the same issue if you specify the same headers as suggested there.
Google Cloud Storage is content-type agnostic, i.e., it treats any kind of content in the same way (videos, music, zip files, documents, you name it).
But just to give some idea,
First I believe that the video () you are uploading is more or less size after it being uploded. so , it falls in application/<sub type>. (similar to section 3.3 of RFC 4337)
To make this correct, I believe you need to fight with storing mp4 metadata before and after the file being uploaded.
please let us know of your solution.
A solution that worked for me in a similar situation is below. TLDR: Save video from web app to GCS with content type video/mp4 instead of application/stream.
Here is the situation. You want to record video in the browser and save it to Google Cloud Storage with a content type set to video/mp4 instead of application/octet-stream. User records video and clicks button to send video file to your server for saving. After sending the video file from the client to your server, the server sends the video file to Google Cloud Storage for saving.
You successfully save the video to Google Cloud Storage and by default GCS assigns a content type of application/octet-stream to the video.
To assign a content type video/mp4 instead of application/octet-stream, here is some server-side Python code that works.
storage_client = storage.Client()
bucket = storage_client.bucket(bucket_name)
blob = bucket.blob(destination_blob_name)
blob.upload_from_file(file_obj, rewind=True)
blob.content_type = 'video/mp4'
blob.patch()
Here are some links that might help.
https://cloud.google.com/storage/docs/uploading-objects#storage-upload-object-python
https://stackoverflow.com/a/33320634/19829260
https://stackoverflow.com/a/64274097/19829260
NOTE: at the time of this writing, the Google Docs about editing metadata don't work for me because they say to set metadata but metadata seems to be read-only (see SO post https://stackoverflow.com/a/33320634/19829260)
https://cloud.google.com/storage/docs/viewing-editing-metadata#edit