1

I am authoring a service with a REST API, that gives people the ability to upload certain kinds of documents. I would like these documents to be compressed during upload (for bandwidth reasons) but they are not stored in my service in a compressed manner. I do have a client SDK, but customers are free to implement their own libraries to upload content based on the REST documentation that I put out. I've looked at the top answer here and determined that transfer encoding might be the more appropriate mechanism to do this.

However, there is very scant documentation/examples on enabling transfer encoding during a PUT request. The RFC seems to spend a good deal of text around transfer encoded responses from the server, but not the other way around.

Should I choose to go down this route, I wanted to get clarification on a few things:

  1. As per RFC 7230, transfer encoding of gzip must always use a second encoding of chunked. In my case, it is not strictly required as the sender does know the full length of the file being sent. But as per the standards I must implement chunked encoding on the server. The RFC indicates that content-length should not be specified if Transfer Encoding is specified, and the chunked encoding framing should be used to delineate the end of the message. Is this accurate? I ask this as my service will need to support chunked-encoding, and I'd like to avoid authoring that if possible.
  2. For transfer-encoded responses, there is a mechanism (TE: Transfer-Encoding:) for the server to negotiate with the client the algorithm that it supports. But there is no such mechanism for client to server interactions. If for some reason, in future, I want to stop support of gzip transfer-encoding at my service, is there any alternative other than returning back 501 (not implemented) errors to the client? This would be a breaking change of sorts and could render some clients to stop working completely. Ideally, I would like the client to query if the server supports a specific encoding, and only then start sending messages using that encoding. Are there any interesting ways this can be done?
Community
  • 1
  • 1
user9476940
  • 11
  • 1

1 Answers1

1

gzip as a transfer encoding isn't implemented widely (if at all), nor does it exist in HTTP/2.

Did you consider gzip as a content encoding? See https://greenbytes.de/tech/webdav/rfc7694.html for more information.

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • I did look at content-encoding, but it seems to imply that the caller can retrieve the content encoded as gzip in a GET request, which as I mentioned is not what I would like to support. – user9476940 Mar 12 '18 at 13:40
  • It doesn't necessarily imply that. That said, why would't it make sense? – Julian Reschke Mar 12 '18 at 18:15