dafortune / hapi-qs

Bring back qs support for hapi 12
10 stars 7 forks source link

Wrong payload #12

Open ro-ka opened 8 years ago

ro-ka commented 8 years ago

The payload is set to an object but it should be empty. That causes an error in hapijs/h2o2. To reproduce, here is the minimal setup.

package.json

{
  "name": "hapi-h2o2-error",
  "version": "1.0.0",
  "main": "index.js",
  "dependencies": {
    "good": "^7.0.1",
    "good-console": "^6.1.2",
    "good-squeeze": "^4.0.0",
    "h2o2": "^5.1.0",
    "hapi": "^13.5.0",
    "hapi-qs": "^1.1.1"
  }
}

The index.js:

var Hapi = require('hapi');
var server = new Hapi.Server();

server.connection({host: 'localhost', port: 3000});

server.register([
  require('h2o2'),
  require('hapi-qs'),
  {
    register: require('good'),
    options: {
      reporters: {
        console: [{
          module: 'good-squeeze',
          name: 'Squeeze',
          args: [{log: '*', response: '*'}]
        }, {
          module: 'good-console'
        }, 'stdout']
      }
    }
  }
], (error) => {
  if (error) {
    throw error;
  }

  server.route([  {
    method: 'GET',
    path: '/test',
    handler: {
      proxy: {
        passThrough: true,
        mapUri: (request, callback) => {
          callback(null, 'https://api.github.com/users/ro-ka');
        }
      }
    }
  }]);
});

server.start(error => {
  if (error) {
    throw(error);
  }

  server.log('info', `Server running at: ${server.info.uri}`);
});

I installed good for logging. What causes this error is this header: Content-Type: application/x-www-form-urlencoded. So when using curl, this is what happens:

~ – curl 'http://localhost:3000/test' -H 'Content-Type: application/x-www-form-urlencoded'
{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"}

~ – curl 'http://localhost:3000/test'
{
  "login": "ro-ka",
  "id": 840022,
  "avatar_url": "https://avatars.githubusercontent.com/u/840022?v=3",
  "gravatar_id": "",
  "url": "https://api.github.com/users/ro-ka",
  …
}

The error only occurs when the header set. The payload is an empty object which breaks the proxy plugin. Can the payload be set to null or an empty string when there is nothing parsed?

dafortune commented 8 years ago

Hey, thanks for pointing out the issue and also for your PR. Part of this plugin goal is to bring back the same behavior qs feature used to have on Hapi<=11, I've tested it and did see that current behavior is the one expected on hapi@11, so I don't think that changing the default behavior is good in this case.

Having said that, I do see what you pointed out as an issue since it limits integration with other plugins. Going a bit deeper in the issue I think that the root problem is that we need to be able to disable the plugin in a route basis.

ro-ka commented 8 years ago

Hi! Yes, I think there might be more possible incompabilities with other plugins. For my problem I managed to get rid of the Content-Type header.