		@@ -943,2 +943,3 @@
		- `encoding` - encoding to be used on `setEncoding` of response data. If `null`, the `body` is returned as a `Buffer`. Anything else (including the default value of `undefined`) will be passed as the [encoding](http://nodejs.org/api/buffer.html#buffer_buffer) parameter to `toString()` (meaning this is effectively `utf8` by default). (Note: if you expect binary data, you should set `encoding: null`.)
		- `statusMessageEncoding` - if provided, this will be passed as the [encoding](http://nodejs.org/api/buffer.html#buffer_buffer) parameter to `toString()` to convert the status message buffer. Otherwise, status message will returned as a string with encoding type `latin1`. Providing a value in this option will result in force re-encoding of the status message which may not always be intended by the server - specifically in cases where server returns a status message which when encoded again with a different character encoding results in some other characters. For example: If the server intentionally responds with `ð\x9F\x98\x8A` as status message but if the statusMessageEncoding option is set to `utf8`, then it would get converted to '😊'.
		- `gzip` - if `true`, add an `Accept-Encoding` header to request compressed content encodings from the server (if not already present) and decode supported content encodings in the response. Note: Automatic decoding of the response content is performed on the body data returned through `request` (both through the `request` stream and passed to the callback function) but is not performed on the `response` stream (available from the `response` event) which is the unmodified `http.IncomingMessage` object which may contain compressed data. See example below.
		@@ -945,0 +946,0 @@ - `brotli` - if `true`, add an `Accept-Encoding` header to request Brotli compressed content encodings from the server (if not already present).

request.js

		@@ -1331,2 +1331,26 @@ 'use strict'

		// Node by default returns the status message with `latin1` character encoding,
		// which results in characters lying outside the range of `U+0000 to U+00FF` getting truncated
		// so that they can be mapped in the given range.
		// Refer: https://nodejs.org/docs/latest-v12.x/api/buffer.html#buffer_buffers_and_character_encodings
		//
		// Exposing `statusMessageEncoding` option to make encoding type configurable.
		// This would help in correctly representing status messages belonging to range outside of `latin1`
		//
		// @note: The Regex `[^\w\s-']` is tested to prevent unnecessary computation of creating a Buffer and
		// then decoding it when the status message consists of common characters,
		// specifically belonging to the following set: [a-z, A-Z, 0-9, -, _ ', whitespace]
		// As in that case, no matter what the encoding type is used for decoding the buffer, the result would remain the same.
		//
		// @note: Providing a value in this option will result in force re-encoding of the status message
		// which may not always be intended by the server - specifically in cases where
		// server returns a status message which when encoded again with a different character encoding
		// results in some other characters.
		// For example: If the server intentionally responds with `ð\x9F\x98\x8A` as status message
		// but if the statusMessageEncoding option is set to `utf8`, then it would get converted to '😊'.
		var statusMessage = String(responseContent.statusMessage)
		if (self.statusMessageEncoding && /[^\w\s-']/.test(statusMessage)) {
		responseContent.statusMessage = Buffer.from(statusMessage, 'latin1').toString(self.statusMessageEncoding)
		}

		if (self._paused) {
		@@ -1333,0 +1357,0 @@ responseContent.pause()

postman-request - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics