I'm building a simple proxy with php for server side and javascript for the client side (browser).
the php server receives post requests with json data , something like that:
{headersArray: ["Get /someurl...","Cookie: some cookie"],url...}
than after extracting the headers and the url the php code uses curl to fetch the resource , and at this point i would like to construct a response object on the client via the "Response" constructor , so i need to transmit back to the client the headers also so i thought about constructing again a json object which will contain the headers and the response body , but a lot of servers uses gzip encoding, can i insert the gzip encoded response body as a json property and safely transmit it back to the client? would i need to decode it on the client browser? does it add a lot of overhead? any better ideas?
Related
I have a confusion while using the bodyparser.Why do we actually need bodyparser when we have json.stringify(to convert object to string) and json.parse(to convert JSON to object)
is it because using it in our app.use() automatically applies the middleware during the interchange of data between client and the server? and we don't need to specify each time when the sending the data from client to server and vice versa?
and if it is so what is the difference between urlencoded and json in bodyparser?
Yes, you are correct. Body-parser is a middleware that automatically parses incoming request bodies and makes the data available in req.body property. It eliminates the need to manually parse the request body each time a request is made, saving time and reducing the risk of bugs.
The difference between urlencoded and json in body-parser is the format of the incoming request body. urlencoded is used when the request body is encoded as URL-encoded strings (i.e. x-www-form-urlencoded) while JSON is used when the request body is in JSON format. By using both, you can handle different types of request bodies.
Why do we actually need bodyparser when we have json.stringify(to convert object to string)
The body parser is also responsible for reading the data from the network stream of the HTTP request in the first place. You can't parse data until you have it.
what is the difference between urlencoded and json in bodyparser?
They parse bodies written in different data formats. The urlencoded format is the default encoding format for a <form>.
I am building a frontend application in which I'm going to retrieve files via the API provided from backend.
The API consumes json request like most restful APIs whereas responses file in multipart/form-data type. Therefore when I tried to get the body of the response with axios, data appears like this.
--77d4f4ac-bcb2-4457-ad81-810cf8c3ce47
Content-Disposition: attachment; filename=20170822.txt
Content-Type: text/plain
...data...
--77d4f4ac-bcb2-4457-ad81-810cf8c3ce47--
It confused me quite a lot since I'm used to deal with raw data with blob object. However it seems that I have to parse the response by myself here in order to get the raw data. I searched around but found almost all of the articles and questions are discussing about server-side handling. So my question can be separated into 2 pieces.
Is it okay/possible to handle multipart/form-data on client side?
If it is, how can I handle it? (Of course, it will be really appreciated if there's a library for it)
If I use:
xhr.setRequestHeader("Content-Type", "application/json");
Am I forced to receive a json response also ? Or I can receive a html response instead?
If I can receive any format I want, what is the best way to dynamically manage this 2 aspects:
the way that I will parse the response (to parse a json or not)
what Accept header to use
For example my function should set:
xhr.setRequestHeader('Accept', "application/json");
in case it waits for a json response, but also do a json parse on the response also, but in case it's a html reponse there is no need for something like this.
So is there any way to manage dynamically the response handling?
Actually content-type is the data type you want to send to the server . on the other hand data-type or as you mention accept is used to negotiate with server which kind of data you are expecting . So as a client you can request multiple data types e.g
httpRequest.setRequestHeader('Accept', 'application/json, text/xml');
But you are responsible to handle the data-type you mention to parse on client side . on server side it is decided by server during negotiation time to produce your desired data-type such as xml,json ,html etc.
So finally you are you are only responsible for the data format you requested. if you request json , then probably the server response data will be json not xml but you have to remember it depends on server side which data-type choice it has, most of the time its json or xml (will known data exchange fromat) then you dont have to request html ,and this mechanism is called content negotiation
Am I forced to receive a json response also?
No. The format of the data you send and the format of the data you receive are unrelated.
Or I can receive a html response instead?
You can.
the way that I will parse the response (to parse a json or not)
Read the Content-Type response header and use it to determine what format the data is in.
what Accept header to use
Ask for a data format that you:
are comfortable parsing and processing
know that server is able to send
We are using window.location() to download files from server. We are sending a JSON string along with request. As this being a GET request, I am forced to have restriction on the length of the JSON string. How can I send more data with window.location? sort of POST request to download the file.
Sounds like you want to download a file using POST method..?
One method is to create a hidden form with post method and submit it using javascript. Then the server has to respond back with a content-disposition header to download the file.
If you can't add this header, then you have to send a post request using ajax and then save the response you get back using version client-side technics like: FileSaver or StreamSaver
What is the difference between sending data through the request header and sending data through the request body. Under what circumstances, we have to send the data through the header/body and when shouldn't we send the data through header/body ?
It is usually a good idea to use the headers for metadata and the body for the data that is used by the business logic.
Some points to consider:
1) If the data is sent via HTTP instead of HTTPS, the proxy servers can modify the headers.
2) If you are using the REST protocol for communication among microservices, interoperability could be important. Most APIs usually do not provide the capability to add/modify custom headers.
3) It is better to have the data that is used by routers/firewalls in the HTTP header and limit the body to application specific information.
A message(request) body is the one which carries actual HTTP request data (including form data and uploaded etc.) and HTTP response data from the server (including files, images etc).
While request header can not contain actual data as mentioned above, you can use request header to send some specific header and based on that you can apply your logic. For instance, while creating a REST API you can send AUTHENTICATION header to verify if request is coming from an allowed user or not.