We are having an issue with sending MMS with PNG images. We previously use that and all works well now it failed.
The code example is here:
$client = new Client(env('TWILIO_SID'), env('TWILIO_TOKEN'));
$message = $client->messages->create(
$number,
[
'from' => env('TWILIO_FROM'),
'body' => $content,
"statusCallback" => "https://OUR_URL.com/api/twilio_web_hooks",
"mediaUrl" => $image_url,
]
);
We get this error:
12300 Twilio is unable to process the Content-Type of the provided URL. Please see Twilio's documentation on accepted content types for more information on valid Content-Types.
Use a HEX editor and see if you see PNG towards the top.
PNG files start with 'PNG', . jpg files should have 'exif'or 'JFIF' somewhere in the beginning.
Related
I am playing with google speech recognition API and have some trouble with file encoding.
Firstly, I tried the API using the Google's HTML form ( https://cloud.google.com/speech-to-text/ ) by file uploading a mp3. It worked nicely, so I have created a Google Cloud project and tried to do that by API using PHP. However, I can't get it to work, it always return empty response.
I am using Google's example code:
$projectId = 'xx';
# Instantiates a client
$speech = new SpeechClient([
'projectId' => $projectId,
'languageCode' => 'sk-SK',
]);
# The name of the audio file to transcribe
$fileName = 'D:\ts\all.mp3';
# The audio file's encoding and sample rate
$options = [
'encoding' => 'LINEAR16',
'model' => 'default',
'sampleRateHertz' => 44100,
];
# Detects speech in the audio file
$results = $speech->recognize(fopen($fileName, 'r'), $options);
var_dump($results); // array(0)
foreach ($results as $result) {
echo 'Transcription: ' . $result->alternatives()[0]['transcript'] . PHP_EOL;
}
When I looked deeper, I noticed, that when I am uploading the mp3 file through the browser, the same file is encoded differently than when using the API.
These are the first 615 characters of encoded audio data sent to API by browser (working):
UklGRiQoEABXQVZFZm10IBAAAAABAAEARKwAAIhYAQACABAAZGF0YQAoEAAFAAQAAgD8//b/8P/q/+r/7P/u//L//f8EAAkAEQAaACMALgA1AD4ATABNAE0AUwBLADoALwAeAAoA/P/o/9n/z/+6/6D/iv9n/zr/FP/z/tv+1/7p/g7/Q/94/6z/4f8DAAwACADz/8z/p/+N/4D/hf+S/67/0P/c/9b/xf+l/37/Xf9Q/1z/Z/90/5j/wf/g//P//f8QACgAJwA4AF4AfgCmAMoA0ADBAHgA+/+B/+j+Mv6x/VD9//zl/Nj80fzd/ML8n/yh/IT8Yfx9/LT8E/2y/W3+Vf9dAEUBFwLHAjMDfQO8A/MDMwRoBJwEzgTLBJ8EYwQMBLgDbQM5A0wDZQNPA0MDLwPyAq0CTQL3Ad8BugGPAZoBkQFVAf0AfAAAAIj/6P54/mH+Zf5+/qL+yv4I/yH/Dv8T/y7/VP+R/+P/VwDNABUBSAFqAWUBQAH+ALYAcAAmAAoACADj/9X/3P+6/4b/SP/7/r3+Z/4W/gL+5P28/dD98/0P/kL+gf7M/gD/Bv8P//X+nv5E/tv9eP1D/RP9Cv08/V79jf3o/Sf
And this is made by Google's PHP library (not working):
SUQzBAAAAAABClRYWFgAAAASAAADbWFqb3JfYnJhbmQAaXNvbQBUWFhYAAAAEwAAA21pbm9yX3ZlcnNpb24ANTEyAFRYWFgAAAAkAAADY29tcGF0aWJsZV9icmFuZHMAaXNvbWlzbzJhdmMxbXA0MQBUU1NFAAAADwAAA0xhdmY1OC4xNy4xMDEAAAAAAAAAAAAAAP/7UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEluZm8AAAAPAAABzQAC8XcAAwUICw0PExUXGh0fISQnKSwuMTQ2ODs+QEJGSEpNUFJUV1pcX2FkZ2lrbnFzdXl7fYCDhYeKjY+SlJeanJ6hpKaorK6wtLa4ur3AwsXHys3P0dTX2dvf4ePn6evt8fP1+Pv9AAAAAExhdmM1OC4yMQAAAAAAAAAAAAAAACQEQAAAAAAAAvF3QasUAQAAAAAAAAAAAAAAAAAAAAD/+5BkAAAC+xrGhWMAAAAADSCgAAEbxZlRuYwAEAAANIMAAACKNzL/lp0F4GTkLOAIBnGAjoLsTctnbL2xAAh3udXmkKV8XqUkofxnbO3fo4gwxdjqQGoAoI1x/HYaw1yTMrLkIONMqw2
The Google's PHP library is using base64_encode method to format the request, but I don't know what type of encoding uses the browser.
When I modify the Google's PHP libraries and force the API to send the correct data (as was sent by browser), it works and I am getting correct results.
So the question is, why is the Google's example not working for me and how to correctly encode the file?
Solved, the file needs to be converted to WAV. It's probably happening by javascript when uploading the mp3 by form.
I need convert html or docx use grive api.
My code
$client = new \Google_Client();
$client->setAccessToken($_SESSION['access_token']);
$service = new \Google_Service_Drive($client);
$content = file_get_contents('template.html');//template.docx
$fileMetadata = new \Google_Service_Drive_DriveFile(array(
'name' => 'test', // name file
'mimeType' => 'application/pdf', // mime type for save in gdrive
//'parents' => array($id_folder)
));
$file = $service->files->create($fileMetadata, array(
'data' => $content, // file
'mimeType' => 'text/html', // application/vnd.openxmlformats-officedocument.wordprocessingml.document
//'uploadType' => 'multipart',
'fields' => 'id')); //
File upload to dgrive normal but when I open it test.pdf i see this error
Failed to load other pages
But my file have only one page.
How can I solve this problem?
See the examples here. In Particular I dont think you need to have fields element in there which i cant find in documentation. When you upload file as text/html make sure you have correct meta data and enable multi-part as you are doing both content and meta data in one go.
I would also suggest doing it in small steps and first let it be very simple html content and try that if that works it might be the case with your content that is not letting pdf come out as normal.
If you work through some of these examples then it would be easy to debug if the problem is in meta data, content or anything else.
I'm trying to upload files to Google Drive but with the attribute convert=true to allow a automatic conversion of upload file to Google Docs format...but it does not work:
$drive_service = new Google_Service_Drive($client);
$file = new Google_Service_Drive_DriveFile();
$file->setTitle("Informe-imaxbd-alfa");
$result = $drive_service->files->insert($file, array(
'data' => file_get_contents("notas-gdrive.docx"),
'mimeType' => 'application/octet-stream',
'uploadType' => 'multipart',
'convert' => FALSE,
));
The file is properly uploaded but without any conversion, why?
You are correct, that the proper mime type Google Drive API accepts is application/msword. I also found out as of writing this, Google Drive API does not support Word .docx format conversion for some reason.
So make sure that not only your extension is in .doc format, but actual document content is also older .doc (Word 97 - 2004) format.
I have a website here http://www.voclr.it/acapellas/ my files are hosting on my Amazon S3 Account, but when a visitor goes to download an MP3 from my website it forces them to stream it but what I actually want it to do is download it to there desktop.
I have disabled S3 on the website for now, so the downloads are working fine. but really I want S3 to search the MP3s
Basically, you have to tell S3 to override the content-disposition header of the response. You can do that by appending the response-content-disposition query string parameter to the S3 file url and setting it to the desired content-disposition value. To force download try:
<url>&response-content-disposition="attachment; filename=somefilename"
You can find this in the S3 docs. For information on the values that the content-disposition header can assume you can look here.
As an additional information this also works with Google Cloud Storage.
require_once '../sdk-1.4.2.1/sdk.class.php';
// Instantiate the class
$s3 = new AmazonS3();
// Copy object over itself and modify headers
$response = $s3->copy_object(
array( // Source
'bucket' => 'your_bucket',
'filename' => 'Key/To/YourFile'
),
array( // Destination
'bucket' => 'your_bucket',
'filename' => 'Key/To/YourFile'
),
array( // Optional parameters
**'headers' => array(
'Content-Type' => 'application/octet-stream',
'Content-Disposition' => 'attachment'**
)
)
);
// Success?
var_dump($response->isOK());
Amazon AWS S3 to Force Download Mp3 File instead of Stream It
I created a solution for doing this via CloudFront functions (no php required since it all runs at AWS by linking to the .mp3 file on Cloudfront with a ?title=TitleGoesHere querystring to force a downloaded file with that filename). This is a fairly recent way of doing things (as of August 2022). I documented my function and how I set up my "S3 bucket behind a CloudFront Distribution" here: https://stackoverflow.com/a/73451456/19823883
According to the docs, contentType is optional and it will attempt to determine the correct mime-type based on the file extension. However, it never seemed to guess the mime-type and always defaults to application/octet-stream
Here's my code:
$s3 = new AmazonS3();
$opt = array( 'fileUpload' => $_FILES['file']['tmp_name'],
'storage' => Amazons3::STORAGE_REDUCED);
$r = $s3->create_object('mybucket', $_FILES['file']['name'], $opt);
Here's a screenshot of my AWS console:
How do you actually automatically set the proper Content Type without setting contentType option, or do you really have to set it manually?
Additional info: If I download a file from the console (that I originally uploaded through SDK) then upload it again using the console, the proper Content-Type is set (ex: image/gif for GIF files instead of application/octet-stream)
Try to add 'contentType' key to your options array when creating object and use 'body' instead of 'fileUpload'. For example:
$s3->create_object('MY_BUCKET', 'xml_file.xml', array(
'body' => '<xml>Valid xml content</xml>',
'contentType' => 'text/xml'
));
Successfully creates file with text/xml content type. As I know Content-Type isn't set automatically when uploading through SDK. But where's the problem to derminate mime type from PHP side and set the 'contentType' property?
I have just run into this situation where, when uploading some files, the Content-Type was not automatically detected. I couldn't figure out what the cause was until I stepped through the code watching the SDK execution. I discovered that the CFMimeTypes::get_mimetype() function, which is used to automatically determine the Content-Type, uses a case sensitive comparison to determine the MIME type. Because of this only lowercase extensions will match. If your file extension is upper or mixed case, then it will not match and fallback to the 'application/octet-stream' MIME type.
To fix change the line:
'fileUpload' => $_FILES['file']['tmp_name']
to
'fileUpload' => strtolower( $_FILES['file']['tmp_name'] )
I am using the SDK v 1.5.8.2, but there doesn't look to be any changes to this detection in the 1.5.9 or 1.5.10 releases that have both come out in the past week. I consider this to be a bug and will be filing it as such.