Clarify gzip handling in the README #972
Conversation
|
Let's stay away from specific use of the terminology around the |
|
Good call. I'll reword it to refer to the streams and reading from the streams without depending on the specific mechanism (either |
|
Would love to get this merged if you have time to clean up the wording a bit :) |
|
Hey @mikeal, sorry for the delay on this. I'll try to carve out some time to clean up this pull request later this evening. I'm looking forward to getting this merged as well. |
|
@kevinoid any updates on this? |
kevinoid
force-pushed
the
gzip-docs
branch
2 times, most recently
from
dc1227f
to
4ee300b
Compare
|
Hey all. My apologies again for the delay. This kept getting bumped down my todo list, but I finally had a chance to make another rev. @mikeal, is this closer to what you had in mind? I promise to be faster about additional follow-up, so don't hesitate to suggest more changes. |
|
Needs rebase against master. |
Make it more explicit in the documentation about which data is unmodified and which is automatically decoded when using the `gzip` option (data passed through request is decoded while the response object is unmodified and thus its data may be compressed). Add an example to README.md to clarify. Changes since v3: - Rebased against current master. Changes since v2: - Make note of gzip example in examples section to alleviate confusion. Changes since v1: - Reworded to refer to streams generically rather than the 'data' event specifically. Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
|
Good call. Rebased. |
|
👍 thanks @kevinoid! I'll merge this tomorrow unless someone objects or beats me to it. |
|
Sounds great, thanks @nylen! |
Clarify gzip handling in the README
Clarify gzip handling in the README
This is a quick documentation update to clear up some confusion from how #951 was implemented. I'd appreciate it if someone could double-check the wording to make sure this is actually legible and explains the behavior clearly enough for users before I merge it. Otherwise, if there are no objections, I'll go ahead and merge it.
Thanks,
Kevin