Warning: The options.bufferType = "string" option is deprecated. Use options.bufferType = "buffer"; instead. #12

Closed
punund opened this Issue Dec 20, 2012 · 7 comments

2 participants

@punund

Shows this message, doesn't work.
Node v0.8.16

@SaltwaterC
@punund

I used the "Shorthand syntax", there was no word that it's deprecated.

besides, it didn't work, and no error was thrown.

@SaltwaterC
Owner

It isn't deprecated. It is a new feature from the same release as the deprecated stuff since I started the library cleanup. There's just one case where it isn't usable without deprecation warnings. That's the get method when it passes a buffer to the callback. Mentioned that into the CHANGELOG, but I guess that most don't read that document.

I'll update the docs to reflect the limitation of the shorthand syntax till the deprecated features are removed. Sorry, can't work around that as it breaks existing code without those warnings, but the refactoring is trivial.

As for the not working part, what exactly is in (error, result)? Can you share an URL for debugging?

@punund

Any URL with two dots starting the path: http://domain.name/../some/path
Browsers redirect from those, excluding the dots part. Still, there shouldn't be no error and no result.

@SaltwaterC
Owner
// http.js
var http = require('http-get')

http.get({
        url: 'http://www.saltwaterc.ro/../wp-download/',
        bufferType: 'buffer',
}, function (err, res) {
        if (err) {
                console.error(err)
        } else {
                console.log(res)
        }
})

This is what I get:

{ [Error: HTTP Error: 400]
  code: 400,
  headers: 
   { server: 'cloudflare-nginx',
     date: 'Thu, 20 Dec 2012 21:25:04 GMT',
     'content-type': 'text/html',
     'content-length': '120',
     connection: 'close' },
  document: <Buffer 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 61 64 3e 3c 74 69 74 6c 65 3e 34 30 30 20 42 61 64 20 52 65 71 75 65 73 74 3c 2f 74 69 74 6c 65 3e 3c 2f 68 65 61 64 3e ...>,
  largeDocument: false,
  noDocument: false }
{ [Error: Parse Error] bytesParsed: 276, code: 'HPE_INVALID_CONSTANT' }

With url: 'http://www.google.com/../' I get:

{ [Error: HTTP Error: 404]
  code: 404,
  headers: 
   { 'content-type': 'text/html; charset=UTF-8',
     'x-content-type-options': 'nosniff',
     date: 'Thu, 20 Dec 2012 21:27:25 GMT',
     server: 'sffe',
     'content-length': '934',
     'x-xss-protection': '1; mode=block' },
  document: <Buffer 3c 21 44 4f 43 54 59 50 45 20 68 74 6d 6c 3e 0a 3c 68 74 6d 6c 20 6c 61 6e 67 3d 65 6e 3e 0a 20 20 3c 6d 65 74 61 20 63 68 61 72 73 65 74 3d 75 74 66 2d ...>,
  largeDocument: false,
  noDocument: false }
@punund

I think I just hit a strangely configured server, can't reproduce.

@punund punund closed this Dec 20, 2012
@SaltwaterC SaltwaterC added a commit that referenced this issue Jan 8, 2013
@SaltwaterC Fixes the too chatty deprecation warning when the download target is …
…a file or null as notified in #12. Fixes the response.url property which was present even though there wasn't

a redirect in place, but the documentation states otherwise.
e4e6287
@SaltwaterC
Owner

Fixed the issue with the too chatty deprecation warning. It was enable for the file download target / null as well, but due to editing a large number of unit tests when the feature was implemented, this case sliped at the testing phase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment