Is it possible to send binary chars feom the client to server via post ?
Should i encode it in the client before sending ?
Or something else ?
Yes it is possible to send binary data from client to server. That's exactly what happens when you use a form with enctype="multipart/form-data" to upload files. Binary data is sent. It is not necessary to encode data on the client before sending. Another example is writing raw bytes in a POST request body which could be read on the server using Request.InputStream.
Related
I am trying to POST with URL encoded data. Based on the web server logs, I am not actually sending any data from Twilio (request size is always 131 bytes, no matter what I type in the Studio widget box).
What does a working form body look like? Do I need to encode it myself? How do I escape an "=" that is not part of the key-value structure?
When making an HTTP request with the widget, when it is set to make Form URL encoded requests you can set the HTTP parameter keys and values which will automatically encode the values. There are known as URL parameter as the encoding is Form URL encoding. The parameters are encoded as if they were in a URL, but they are sent as the POST body.
I know how to send any file via FileResponse and also know how to send plaintext or custom Response in fast-api. However, I cannot figure as to how can I send info as Json along with a large file attachment. My need is to send information as Json along with file as attachment. Thanks
I am looking for a way to send a post request to a specific URI from PowerApps.
Basically I have a small audio file (webm) captured from the microphone and it's encoded using Base64. Now I have to send it to a server via post request and the encoded data should be put in the body of the request, since it is too big (for Nginx) to be put in the URL itself (?data=).
Can I achieve it in PowerApps?
Binary to encoded text (in PowerApps):
Set(BinaryAudioData_2, Substitute(JSON(Mic2.Audio,JSONFormat.IncludeBinaryData),"""",""));
Set(AudioFile, Mic2.Audio); Collect(Collection3, AudioFile);
You can trigger a Power Automate Flow from PowerApps, then Flow can target the specific URI. Read more
I have difficulty in understanding how this header works.
Briefly my question is
If i am requesting a post to certain resource then let's
Say in 1st case response is some json string and in 2nd case response is a .jar file.
1.Should client include accept-header:gzip,deflate in both cases while sending HTTP request,knowing that first one results in json string?
2.What if the response is already zipped,now zipping the response over the already zipped data doesn't create problems?
3.what happens if i include accept-encoding:gzip in first case where json string is received. So i receive a zipped data as my response(i am not even sure if get zipped data or some encoded data as response.I think zipped data means something zipped like .jar/.zip and encoded data means Encoded data of the original data ,which one is happening zipping or encoding)?
4.Lets say the server sends the response with Contentype header as "application/octet-stream". Now is it must to use accept-header:gzip,deflate
A client can use Accept-Encoding HTTP request header to tell the server that it can accept a compressed response.
The server can use the request header to decide if it should send a compressed response or not. It can ignore the header and always send a non-compressed response (possibly less efficient). It can ignore the header and always send a compressed response (risking giving a client a response it can't decode).
Should client include accept-header:gzip,deflate in both cases
I can't think of any reason to not tell the server that a client can handle a compressed response (assuming that fact is true).
What if the response is already zipped,now zipping the response over the already zipped data doesn't create problems
It might be a waste of processor power for little or no saving in bytes.
That's not a reason for the client to say it can't handle a compressed response though. That's a decision to be made on the server.
what happens if i include accept-encoding:gzip in first case where json string is received.
Then the client has told the server that a compressed response is acceptable.
So i receive a zipped data as my response
The server might send a compressed response. It might ignore the header.
i am not even sure if get zipped data or some encoded data as response
There isn't an "or" here.
The data is encoded using a compression algorithm.
Lets say the server sends the response with Contentype header as "application/octet-stream"
That just means the server doesn't know what type of data it is sending. Instead of saying "This is JSON" or "This is a jar file" it is saying "I dunno what this is, it's just a stream of bytes to me".
Now is it must to use accept-header:gzip,deflate
It doesn't make a difference.
The server can compress the data. It can send uncompressed data. It can use the Accept-Encoding request header to decide which of the two.
Yes, why not? If the JSON payload is big, compressing it will make a lot of sense.
It's just overhead.
You might receive gzipped data - not a ZIP file. You may want to read RFCs 7230 and RFC 7231 for details.
The internet media type of the payload is completely independent of the content coding.
I'm sending some pre-encrypted strings (AES) to a REST API, this is data that has been encrypted by the client. I am storing the data, and never decrypting it on the server side.
I will hand it back to the client later.
My initial thought was to use base64 encoding to ensure the data survives the form post. Is this the correct way to do things?
You do not need any special encoding to POST data to a server, as there is no restriction to what characters you can use.
If you choose to send the encrypted data as binary data, you should specify content-type header to be application/octet-stream.