Feature Request: add support for custom request Content-Encoding (such as gzip) #52
Comments
|
ack. Yeah I saw this coming :) ps do you mind reviewing #53? I want to ensure we have time to address features like this by trimming edge-case code. |
|
I suspect this would need to be a part of the Encoder or possibly a revision to RequestInterceptor you only need encoding? |
|
I've reviewed the ticket you mentioned. For my current use case, I only need the ability to gzip-encode the request body; no need to do any special decoding. If RequestTemplate were structured to allow for treating the body as a byte[] rather than a String, I could accomplish this via a RequestInterceptor that added a Content-Encoding header and replaced the pre-existing body with the gzip-ed version. The API I'm integrating with takes a POST of either an XML or JSON document as the body, but requires that the body is gzip-encoded. I'm currently approaching it using JSON, encoded via the GSON module. The Encoder interface doesn't currently allow for meeting this need, as Encoders currently always need to return a String, and this encoding would return a byte[]. If it returned a byte[](or similar representation of binary data), then this approach could work. I'd likely extend the GSON encoder to also GZIP compress. After having thought this through, I think that it may be better to first work on a new feature of "support binary bodies". This seems like a sensible, general-use feature by itself (for example, file/image uploads to a REST endpoint), and seems likely to provide the majority of the structural changes needed to make this particular use case workable. |
|
I was thinking similarly. That said, clients like ok http are handling |
|
A decorator sounds good for now. I'll put one together Monday. No need for an example. Thanks. |
|
On second thought, given the way that the Client and Request are currently structured, I don't think a decorator is workable. For that to work, I'd need to take the original request, perform the gzip encoding modifications to it, and then pass it to the delegate's execute method. That isn't possible for exactly the same reason as it isn't possible to handle this as a RequestInterceptor: the Request is treating the body as a String, rather than some binary form. In the following gist, I've included an example client that does what I need it to for now. It contains mostly the same code as the default client, with the following additions:
|
|
If you don't mind, move this code into the default client in a Pull Request. As there's no binary body supported as yet, there's no chance this approach would conflict with expectations. |
|
Sure. I'll work on making this into a pull request. |
default client: add support for gzip-encoded request bodies (#52)
Enhances the default client to GZIP-encode request bodies when the appropriate content-encoding header is set in the interface's method definition. #52
* Skip filename in Content-Disposition if it's null. When making an upload from a byte[] there isn't a filename and the Content-Disposition header ends up with a value ending in filename="null" which can result in consuming services thinking null is should be used as a filename. Instead when it's a byte[] upload we shouldn't output the filename. The filename part of the Content-Disposition header is optional(see RFC-6266). Fixes OpenFeign#52 * Fixed indentation.
* Skip filename in Content-Disposition if it's null. When making an upload from a byte[] there isn't a filename and the Content-Disposition header ends up with a value ending in filename="null" which can result in consuming services thinking null is should be used as a filename. Instead when it's a byte[] upload we shouldn't output the filename. The filename part of the Content-Disposition header is optional(see RFC-6266). Fixes #52 * Fixed indentation.
Enhances the default client to GZIP-encode request bodies when the appropriate content-encoding header is set in the interface's method definition. #52
default client: add support for gzip-encoded request bodies (#52)
* Skip filename in Content-Disposition if it's null. When making an upload from a byte[] there isn't a filename and the Content-Disposition header ends up with a value ending in filename="null" which can result in consuming services thinking null is should be used as a filename. Instead when it's a byte[] upload we shouldn't output the filename. The filename part of the Content-Disposition header is optional(see RFC-6266). Fixes #52 * Fixed indentation.
I have an API that I'd like to use Feign to connect to that requires that the POST request body use gzip content encoding.
This feels to me like something that should be possible using a RequestInterceptor, but the current structure of RequestTemplate (storing body as String, and converting to bytes in the client) doesn't really seem like it supports it. I know I could add support for this using a custom Client implementation. Is there a better approach?
The text was updated successfully, but these errors were encountered: