I asked this question a few days ago, and I did not get much activity on it. And it made me think that maybe it was because my question was meaningless.
My understanding of http is that the client (a typical browser) sends a request (receive) to the server, in my case IIS. Part of this request is the accept-encoding header, which tells the server what type of encoding the client would like to return the resource. This can usually include gZip. And if the server is configured correctly, it will return the resource requested in the requested encoding.
The response will include a Content-Encoding header indicating what compression has been applied to the resource. The response also includes a Content-Type header, which indicates the mime type of the resource. Therefore, if the response includes both Content-Type: application / json and Content-Encoding: gzip, the client knows that the resource is json, which was compressed using gzip.
Now the scenario that I came across is that I am developing a web service for clients that are not browsers, but mobile devices, and that instead of requesting resources, these devices will place data in a serviced service.
So, I implemented the Restfull service, which accepts a mail request with json in the body. And my clients send their mail requests using Content-Type: Application / json. But some of my clients asked them to compress their request in order to expedite the transfer. But I understand that there is no way to indicate in the request that the request body was encoded using gZip.
That is, there is no content header header for requests, only responses.
This is true?
Incorrect use of http to attempt to compress requests?
source
share