hapijs / call Goto Github PK

How come Case Normalization and Percent-Encoding Normalization from RFC3986 are applied to paths in Router#normalize(), but Path Segment Normalization is omitted?

Replaces hapijs/hapi#1927

I think this project deserves some nice documentation to be a lot more accesible to developers. Willing to help!

Replaces #5

Specificity must be compared at each segment regardless of wildcards at the end.

I have three paths:

/path_1
/path_1{extension?}
/path_2{extension?}

Within all of these paths, I have validation using joi set up as such:

• extension: joi.string().regex(/\.(csv)$/) (path_2)
• extension: joi.string().valid('.pdf'). (path_1)

From working through the code here in call, I can see that one of the three paths is matched as a direct string literal (the one that is an exact string literal). The other two are matched after being split into parts, and the individual parts are matched.

Both receipt paths send to the same handler, so extension is either set, or it is null. For sales/report, extension is always set, because the way the path is split up requires it, even if a value is not required. Without adding allow('') to the joi specification, it's rejected, because an empty string does not match without being explicitly allowed. (As is clearly defined in the hapi docs)

I guess my question is what is the expected behavior/design? and why are the trailing ends of trees handled as empty strings instead of null?

Replacing line 262 of segment.js with:

let cleanArray = result.array.filter((a) => a.length > 0 )
return { record: result.record, array: array.concat(cleanArray) };

seems to resolve the issue for me, but I'm sure there are side effects of that action.

Is the recommended pattern for optional extensions:

1. /path_1 and /path_1{extension?} with validation as extension: joi.string().valid('.pdf')
2. /path_2{extension?} with validation as extension: joi.string().allow('').valid('.csv')

Option #2 is nice, because it's a single line, but then extension has to be manually handled as an empty string or the valid string. It's not passed in as null, as you may expect when a string is not required.

I have no idea how to use your tool, please update the README

Hello,

How would one go about implementing route delete/remove method. I'm willing to write code & tests, but since I'm new to the Call's inner workings I wanted to hear from the community first.

Thank you

Disclaimer: this is a duplicate post for hapijs/hapi#2058

According to http://hapijs.com/api#path-parameters and the actual implementation of routes in v7+, one can not register the following route: /{foo}-custom-string-{bar}, due to the restriction that a path segment can not contain more than one parameter.

This should be changed and it should allow the creation of more flexible routes. Not all users of hapi use it to create only API sites, some of us use it to run a user facing site where SEO and the public URL structure is important.

I know we can do this by using a single parameter for the whole segment and then parsing that parameter inside the handler method, but that ruins the whole idea of using a framework that handles these small things for you.

With this configuration of routes:

Route A:

{
  path: '/{slug}',
  vhost: 'sub.example.com'
}

Route B:

{
  path: '/robots.txt'
}

A is having priority over B. I think in this cases B should have a higher priority, don't you think?

I understand that at this moment, the router gets the routing table for the vhost and, if it is not defined, uses the default routing table. Would it be possible to merge those tables?

Support plan

• is this issue currently blocking your project? (yes/no): Sort of
• is this issue affecting a production system? (yes/no): No

Context

• node version: 14
• module version with issue: call
• last module version without issue: -
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): Serverless offline
• any other relevant information:

What are you trying to achieve or the steps to reproduce?

We have an endpoint in a serverless.yml file specified as follows:

      - http:
          path: /features/{entity-id}
          method: post

Serverless offline uses Hapi to generate a local server that allows offline testing of a Serverless application.

Unfortunately we are unable to change the parameter to a _ separated one or camelCase because when deploying the Serverless application it complains because the same path already exists.

What was the result you got?

Error: Invalid path: /dev/features/{entity-id}

What result did you expect?

Not having an error with the path.

Context

The following link is referenced in the documentation and is broken: https://gist.github.com/hueniverse/a3109f716bf25718ba0e

It is referenced on this line: https://github.com/hapijs/call/blame/11bfeb48df8800c51281f2eda3539d6549704d12/API.md#L72

Apologies for opening an issue instead of a PR. I attempted to look for the missing article, but judging from the fact that the gist is no longer accessible and that Eran's blog has been taken down, it looks like he doesn't want his content to be freely available anymore.

What are you trying to achieve or the steps to reproduce ?

I'm trying to help bring attention to the fact that the documentation is not up to date.

{
path: '/{slug}',
vhost: 'sub.example.com'
}

I think the actual route should be the primary decider on if the route is more specific rather then the method. As an example, in a project I'm working on we have a proxy route that is prefixed with /api/ and should be accessible with any method.

server.route({
    method: '*',
    path: '/api/{param*}',
    handler: {
        proxy: {
            mapUri: uriMapper,
            passThrough: true
        }
    }
});

I want that route to be more specific than our route that serves files:

server.route({
    method: 'GET',
    path: '/{param*}',
    handler: function (request, reply) {

        reply.file(Path.resolve('build') + '/index.html');
    }
});

But currently we have to loop through a list of methods and create the api-routes.

The Inert directory handler behaves incorrectly when a route contains dynamic segments and the incoming {path*} part is empty.

Eg. the route /{domain}/{path*} matches /main/, but only includes the domain part in the output with params: { domain: 'main' }, paramsArray: [ 'main' ].

I would expect params: { domain: 'main', path: '' }, paramsArray: [ 'main', '' ].

Note that Inert depends on the length of the paramsArray to determine the last path segment for the directory handler. See hapijs/inert#74 for some background.

I am using call router in non Hapi.js projects. It is one of the most fantastic router I have seen. It is deterministic, reasonably fast and at a same time, it is simple.

Documentation can really help it make standout as a stand-alone module. Please provide documentation for this.

Consider this example:

var Hapi = require('hapi');

var server = new Hapi.Server(3000, {
  router: {
    isCaseSensitive: false,
    stripTrailingSlash: true
  }
});

server.route([{
  method: 'GET',
  path: '/rules',
  handler: function(request, reply) {
    reply(true);
  }
}, {
  method: 'GET',
  path: '/rulePacks',
  handler: function(request, reply) {
    reply(true);
  }
}]);

server.start(function() {
  server.log(['info'], 'Public server started on port: ' + server.info.port);
});

I would expect to be able to make a request for /rulePacks or /rulepacks and have either succeed, however neither do because the original request path is being compared to the route path.toLowerCase(). That check is being performed in https://github.com/hapijs/call/blob/master/lib/index.js#L137.

I think the simple fix would be something along the lines of:

if(!this.settings.isCaseSensitive) {
  record.path = record.path.toLowerCase();
  path = path.toLowerCase();
}

Am I misunderstanding how route case sensitivity is to be used? I noticed this behavior changed between Hapi 6.8.1 and 6.9.0 when this library was introduced.

/download/{filename}.{ext}

Call seems to support the above style, it looks like there's even tests for it. The Routing Tutorial on hapijs.com says this won't work:

you may only have one named parameter per segment. That means that /{filename}.jpg is valid while /{filename}.{ext} is not.

So is this an out of date tutorial of an undocumented feature that shouldn't be relied upon?

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

I realize call protects heavily against route collision. But does call's approach (barring any bugs) make it truly impossible to write two conflicting routes? Just curious!