I can't send exe files in telegram bot
for example this is 7z download link : http://www.7-zip.org/a/7z1604-x64.exe
https://api.telegram.org/botToken/sendDocument?chat_id=chatId&document=http://www.7-zip.org/a/7z1604-x64.exe
When i send this file return me :
{"ok":false,"error_code":400,"description":"Bad Request: wrong file identifier/HTTP URL specified"}
it is possibile send exe file in telegram bot?
Ok. Let's see to documentation:
Sending by URL: n sendDocument, sending by URL will currently only work for gif, pdf and zip files.
You can't send .exe file by URL. Instead of sending by url, in your case you need to
Post the file using multipart/form-data in the usual way that files are uploaded via the browser. 10 MB max size for photos, 50 MB for other files.
Related
I have a very peculiar scenario where the raw data of the file has to be sent. I have tried following options and still wasn't successful.
Http Request with form-data disabled but still its sending as multi-part which is not acceptable by the system
Sending the file contents in request body by following methods . They were successful however the file uploaded was encoded in some format so the MD5 hash of the original file and uploaded file doesn't match. Hence the uploaded file looked different from original
FileToString Method
Reading the file using HTTP request . Capturing the response and passing to the body of File upload request
Using Https Raw data . Since its https request, it cannot be used.
All possible encoding formats available but nothing worked as the application just expects the raw data without any encoding.
You're supposed to provide an example successful request and the file you're uploading, it can be captured using a sniffer tool like Wireshark or Fiddler, only this way we'll be able to come up with the relevant JMeter configuration required to replicate the request.
In the mean time I can only suggest trying recording the request using JMeter's HTTP(S) Test Script Recorder
Start JMeter's HTTP(S) Test Script Recorder
Import JMeter's certificate into your browser (or system certificates storage if the upload is being performed by other application), see HTTPS recording and certificates chapter of JMeter's documentation on HTTP(S) Test Script Recorder
Copy the file you're going to upload to "bin" folder of your JMeter installation (or JMeter's current working directory if you're launching it from a desktop shortcut or whatever), see Recording File Uploads with JMeter for more details
Perform the upload in the browser (or other application)
JMeter should intercept the request and generate proper HTTP Request sampler and HTTP Header Manager
User will upload the videos from browser which need to be stored on server and playback. First understanding from google suggest I need to go for HTTP live streaming(HLS) here.
But I am not sure how it works internally ?
There are three components in above workflow i.e. client/server/data store for saving and retrieving videos.
Save flow :
I believe I need to plugin the HLS client for sending the streaming data.
Does Client in itself divide the file into chunks while sending and maintain the chaining of these chunk where each chunks points to next one ? something like this as I believe server is dumb and will work in same fashion as http upload functionality and no other intelligence is required here ?
But not sure how HLS server side component works here i.e. Will it save as single file or single file is split in to multiple files and then saved on disk ?
I believe it store the file as single file like regular http upload file ?
Retrieval part
In normal regular http file download, client asks for file data and server sends the response back in chunks but all response chunks are sent back against the same request.
I believe in case of HLS , its pull based where client initiate the pull request for each stream request. In each chunk pull request client gets the file name of next chunk and send the request to serverthe relevant chunk from single file for each poll request etc ? So for server its kind of regular http file download request and all intelligence lies with client
Save flow: When you upload a video, it must be converted into HLS format. You can use FFMPEG to do that. You'll end up creating manifest files, and all the segments of the video.
Retrieval part:
The player will read the manifest file to know which segments to request. I've written a post on how HLS playback works with the manifest files: https://api.video/blog/video-trends/what-is-hls-video-streaming-and-how-does-it-work
I'm developing an application with next.js
I have an api endpoint that receives FormData in the request.
I'm using Formidable to get the files from the request.
Than, upload the file from its temporary path on the server to AWS S3.
My question is, how can i validate that the user didn't malformed the path of the file, and sending the request with a malicious path. For example, changing the path to "../../secretFile".
A regular path for example would be:
C:\Users\MyUsername\AppData\Local\Temp\upload_e69daadcd956ae15fc00551832d1be82
I have the zip file download url, link are below:
https://dl.opensubtitles.org/en/download/sub/7790586/vrf-f5760bc3.
I made a request for this URL with the required headers and still I can't download the zip file. It gets redirected to old movie page else download unrelated zip file content. I know there is API available but i need this to be done by script, not by API or selenium.
I tried in both request and scrapy get method still I can't download the correct zip file.
headers = {
"authority": "dl.opensubtitles.org","Connection": "keep-alive",
"user-agent":user_agent,
"accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3","accept-encoding": "gzip,deflate,br","accept-language": "en-IN,en-US;q=0.9,en;q=0.8","referer": movie_url,'upgrade-insecure-requests':'1'}
requests.get(url,headers=headers)
with requests.get(url, stream=True) as res:
with open('test.zip', 'wb') as f:
for chunk in res.iter_content(chunk_size=1024): #you can also change the chunk size
if chunk: # filter out
f.write(chunk)
I have a .jpg file stored in S3 and distributed using CloudFront. I can view the file when I download it, but I cannot view the file in Chrome or Safari. From what I can tell, I can't view the file in a browser because the Content-Type isn't getting sent despite the fact that I've set it in S3.
You can see what happens when you enter this signed CloudFront url into a browser. It should remain valid for roughly 24 hours after this post. https://media.development.doctheapp.com/claims/us-east-1:4877c3da-786a-4b3b-b1e0-c70bde0f9c4e741afc7c5a8304564963080a98e5675d09d1aca3d623911e34bd3b4eb0808579/300ae913-8f88-44b9-a4ab-e46d11133c76/receipt.jpg?Expires=1526533530&Signature=crnjhje1noP-7WfBMI6rMDPd-zdCAVKLaojFFNvxCZEdx0~EJHeqbL8oKwL64AULavekMHm~2r6vHto1d4IAt5eoLpbZR~q5PAfhSakte1iNNvuTxQ7q-mYOwoCemb5VD~bFXUBdrF1yiybaRHw-v6USbw53QZ2Qa4hfDkqgoEKwvEznBvR~sQnk5v-slX8~aJBhySS5XpkfdoE-yl8hh697xIyH~OliwrCg7h5iSkotwW9~EvTnLoVkXkuvru35eLhN4~gGMs3WDUAuucOl8JZdeg6CjAQQ~JWv6FJnb2wyvGrGJzOf70~8s08~qSqiCroyZfqUiZmw20eCIWXp4A__&Key-Pair-Id=APKAJVSE2BEPIQCCPH6Q
It seems like the original image is a TIFF file, not a JPEG. That's why you cannot see it in a browser but can open it upon download. The content type header is being sent correctly by Cloudfront if you look at the response headers.