I have been asked to reduce the bandwidth requirements for our app by compressing data that is sent to the server. I'm trying to do this transparently without changing the API, i.e. continuing to use the same URL and content type. I've found how to code it at How do I enable GZIP compression for POST (upload) requests to a SOAP WebService on IIS 7?
I think there is a risk of a new client being configured to communicate with an old version of the server, i.e. the client sending a compressed request to a server that cannot handle it. I would like to detect support in a standards-compliant way. The problem is, I can't find a source indicating how this should be done.
My thinking was that I should add the Accept-Encoding: gzip header to the OPTIONS response. We're already sending a preflight OPTIONS request for CORS, so piggy-backing seems like it would save latency. But I can't find a source saying that this header is valid in an OPTIONS response. RFC 7231's definition of OPTIONS simply defines the method without going into the details of what can be specified.
Is there any standard for indicating that compressed requests can be sent?
Yes, indeed using Accept-Encoding. See RFC 7694 (https://www.greenbytes.de/tech/webdav/rfc7694.html).