Deflate backwards
smdjeff opened this issue · comments
I don't accept compressed responses to my client so I'm setting
Accept-Encoding: identity
However I do POST compressed data from the client. And this works...
Content-Encoding: gzip
Might as well save 18 bytes per post and switch to deflate without the useless gizp headers and footers. Right? Alas, this fails...
Content-Encoding: deflate
Admittedly, it's unusual to have an asymmetric connection like this, but looking at the library it seems that method actually represents the compression side of the transaction. Is that a bug?
stream = method === 'gzip'
? zlib.createGzip(opts)
: zlib.createDeflate(opts)
This module does nothing with incoming body, not the outgoing (from the server). It would thus not be involved in the encoding of the data that is POSTed to an Express server. That is why you see it using those methods, as this module will compress the response, not decompress the request.
To clarify I am referencing my client's http headers but it's not even written in JS. I'm asking about how the server side (which is JS and uses this module) and how it handles POST where the Content-Encoding: deflate to decrypt those contents.
Related to #136 ?
This module does not do anything when the client sends a content-encoding header. This module is what generates the header in the server response.
The middleware will attempt to compress response bodies for all request that traverse through the middleware
Thank you. I believe the issue is actually in body-parser.
expressjs/body-parser#450
Ah, gotcha. I didn't want to assume what module you were using to parse the incoming body, particularly as there are a lot of them out there to use.