hapijs / call Goto Github PK
View Code? Open in Web Editor NEWHTTP Router
License: Other
HTTP Router
License: Other
Replaces #5
Replaces hapijs/hapi#1927
I think this project deserves some nice documentation to be a lot more accesible to developers. Willing to help!
{
path: '/{slug}',
vhost: 'sub.example.com'
}
🚨 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:
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.
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.
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.
Error: Invalid path: /dev/features/{entity-id}
Not having an error with the path.
How come Case Normalization and Percent-Encoding Normalization from RFC3986 are applied to paths in Router#normalize(), but Path Segment Normalization is omitted?
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 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:
/path_1
and /path_1{extension?}
with validation as extension: joi.string().valid('.pdf')
/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.
Specificity must be compared at each segment regardless of wildcards at the end.
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.
I'm trying to help bring attention to the fact that the documentation is not up to date.
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
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.
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?
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!
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.
I have no idea how to use your tool, please update the README
/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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.