Merge pull request hapijs#448 from pborreli/dev-typos

Fixed typos

docs/Reference.md

@@ -596,7 +596,7 @@ to write additional text as the configuration itself serves as a living document
             - _'user'_ - the authentication must be on behalf of a user.
             - _'app'_ - the authentication must be on behalf of an application.
 
-The `config` option was defined for easily spliting the routing table definition from the individual route information. For example:
+The `config` option was defined for easily splitting the routing table definition from the individual route information. For example:
 ```javascript
 var Hapi = require('hapi');
 
@@ -768,7 +768,7 @@ var handler = function () {
 #### Response
 
 **hapi** provides native support for the following response types:
-- Empty - an empty response body (content-lenght of zero).
+- Empty - an empty response body (content-length of zero).
 - Text - plain text. Defaults to 'text/html' content-type.
 - Obj - Javascript object, converted to string. Defaults to 'application/json' content-type.
 - Stream - a stream object, directly piped into the HTTP response.
@@ -1273,7 +1273,7 @@ The request object is also decorated with the following methods.
     - _'tags'_ - a single string or an array of strings (e.g. _['error', 'database', 'read']_) used to identify the logged event. Tags are used instead of log levels and provide a much more expressive mechanism for describing and filtering events.
     - _'data'_ - an optional message string or object with the application data being logged.
     - _'timestamp'_ - an optional timestamp override (if not present, the server will use current time), expressed in milliseconds since 1970 (_new Date().getTime()_).
-- _'getLog(tags)'_ - Returns an array of events which match the tag(s) specifed.
+- _'getLog(tags)'_ - Returns an array of events which match the tag(s) specified.
 
 For example:
 ```javascript
@@ -1508,7 +1508,7 @@ Error responses are send as JSON payload with the following keys (unless an [err
 - _error_ - the HTTP status message (e.g. 'Bad Request').
 - _message_ - the returned message if provided.
 
-The complete error repsonse including any additional data is added to the request log.
+The complete error response including any additional data is added to the request log.
 
 
 ## State Management

docs/Style.md

@@ -225,7 +225,7 @@
       value = {
           func: function () {
 
-              cosole.log('example');
+              console.log('example');
           },
           message: 'hello'
       };

lib/auth/oz.js

@@ -44,7 +44,7 @@ exports = module.exports = internals.Scheme = function (server, options) {
 };
 
 
-// Request an applicaiton ticket using Basic authentication
+// Request an application ticket using Basic authentication
 
 internals.Scheme.prototype._endpoint = function (name) {
 

lib/defaults.js

@@ -65,7 +65,7 @@ exports.server = {
     // Files path
 
     files: {
-        relativeTo: 'routes'                        // Determines what file and directorie handlers use to base relative paths off: 'routes', 'process'
+        relativeTo: 'routes'                        // Determines what file and directory handlers use to base relative paths off: 'routes', 'process'
     },
 
     // timeout limits
@@ -118,7 +118,7 @@ exports.cors = {
 
 exports.monitor = {
     broadcastInterval: 0,                           // MSec, 0 for immediately
-    opsInterval: 15000,                             // MSec, equalt to or greater than 100
+    opsInterval: 15000,                             // MSec, equal to or greater than 100
     extendedRequests: false,
     requestsEvent: 'tail',                          // Sets the event used by the monitor to listen to finished requests. Other options: 'response'.
     subscribers: null                               // { console: ['ops', 'request', 'log'] }

lib/server.js

@@ -328,7 +328,7 @@ internals.Server.prototype.stop = function () {
 };
 
 
-// Set route defauts
+// Set route defaults
 
 internals.Server.prototype.setRoutesDefaults = function (config) {
 

proposals/RFC.CacheMemorySize.md

@@ -4,9 +4,9 @@
 
 ## Memory Cache Size
 
-The following document details a proprosal for allowing the memory cache strategy to be restricted with a maximum size.
+The following document details a proposal for allowing the memory cache strategy to be restricted with a maximum size.
 
-## Proprosed Solution 1
+## Proposed Solution 1
 
 A very simple solution to this problem is to limit the size by a maximum number of items that can be cached.
 

proposals/RFC.DocGeneration.md

@@ -4,15 +4,15 @@
 
 ## Route Documentation
 
-The following document details a proprosal for generating pretty html markup describing a Hapi route.
+The following document details a proposal for generating pretty html markup describing a Hapi route.
 
 ## Overview of proposed solution
 
 The documentation generator will leverage the existing route config object properties as input into a templating engine.  As a result of a route as well as parameters that a route supports having a description, notes, and a tags property the config object will not need to be modified.  The config details that the generator cares about will be added to a new object that can then be passed into a templating engine.  The output from the templating engine can then be output to the response or to a file that will be served up statically.
 
 ## Route documentation details
 
-In order to keep things simple, when viewing the documentation for a route you will see all of the documentation for the methods that the route handles.  Additionally, you will also see the validation details for individual paramaters that the route accepts.
+In order to keep things simple, when viewing the documentation for a route you will see all of the documentation for the methods that the route handles.  Additionally, you will also see the validation details for individual parameters that the route accepts.
 
 ## Template engine input
 

proposals/RFC.QueryConfig.md

@@ -114,7 +114,7 @@ The second, simpler, and more acceptable method is to alias the new Type within
 
 Thus, subsequent calls to the new "type" will behave as fully registered types in much less code.
 
-*Note: The first method may eventually be deprecated. Then, the Type Registry becomes non-mutable which simplies the logic significantly.*
+*Note: The first method may eventually be deprecated. Then, the Type Registry becomes non-mutable which simplifies the logic significantly.*
 
 *Note: See "Reference A" before suggesting a pre-included Type for the Type Registry.*
 
@@ -335,7 +335,7 @@ Every call must have its own `Base()` prefix. This creates a new validation obje
 
 #### Overrides
 
-Each constraint is evaluated independantly and in order of chaining. In some cases, a subsequent constraint may override a prior constraint:
+Each constraint is evaluated independently and in order of chaining. In some cases, a subsequent constraint may override a prior constraint:
 
     String.required().optional() # This input will be considered optional
     String.required(false).required() # This input will be considered required

proposals/RFC.Throttling.md

@@ -103,7 +103,7 @@ Finally, a configuration option will also need to exist to indicate if a sliding
 
 ## Tracking Usage
 
-When throttling is enabled, every request will need to increment its respected usage count.  However, not every use will necessarily require throttling limits be imposed, therefore a custom function can be added to the throttle configuration to determine if a user is tracked.  Below is what this entry in the configuraiton will look like:
+When throttling is enabled, every request will need to increment its respected usage count.  However, not every use will necessarily require throttling limits be imposed, therefore a custom function can be added to the throttle configuration to determine if a user is tracked.  Below is what this entry in the configuration++ will look like:
 
 ```javascript
     throttle: {

proposals/Routing/RFC.RouteConfig.md

@@ -77,7 +77,7 @@ The above are simple examples that hint at how difficult it can be to foresee, d
 ### Disadvantages of Trees
 
 #### Relative Complements: Computers >> Humans
-The tree structure I propose uses some inheritence for options (opts: {}) which get applied to all descendent controllers. 
+The tree structure I propose uses some inheritance for options (opts: {}) which get applied to all descendant controllers.
 
 Let's assume all controllers use the base opts.  But, later down the line, you add a new controller that should not have the inherited options.  It is not immediately obvious visually that the options will get passed down.  The computer can't really determine whether you intended to use the base opts or not.  
 

proposals/Routing/new_routes.js

@@ -49,11 +49,11 @@ exports.endpoints = {
                 post: { handler: Session.token, data: Session.type.endpoint, authentication: 'optional', user: 'any', tos: 'none' }}},
         "/profile": {
             base: User, // Special param:  handlers for sibling HTTP methods use convention:  base[http_method] = User.get
-            opts: { tos: 'none' }, // default opts, inherited by descendent controllers
+            opts: { tos: 'none' }, // default opts, inherited by descendant controllers
             // get: { tos: 'none' },  // not necessary, covered by existence of User.get;
             post: { data: User.type.user }, // handler unnecessary since following RESTful convention; tos inherited from parent.opts
             "/email": {
-                post: { handler: User.email, data: User.type.email }}} // inherited tos param
+                post: { handler: User.email, data: User.type.email }}}, // inherited tos param
         "/contacts": {
             get: { handler: User.contacts, query: ['exclude'], tos: 'none' }},
         "/who": {
@@ -89,15 +89,15 @@ exports.endpoints = {
                     post: { handler: Last.postProject }},
                 "/participants": {
                     post: { handler: Project.participants, query: ['message'], data: Project.type.participants },
-                    delete: { handler: Project.uninvite, data: Project.type.uninvite }
+                    delete: { handler: Project.uninvite, data: Project.type.uninvite },
                     "/:user": {
-                        delete: { handler: Project.uninvite }}}
+                        delete: { handler: Project.uninvite }}},
                 "/suggestion": {
                     delete: { handler: Suggestions.exclude }},
                 "/suggestions": {
                     get: { handler: Project.suggestions }},
                 "/task": {
-                    put: { handler: Task.put, query: ['suggestion', 'position'],  data: Task.type.put }}
+                    put: { handler: Task.put, query: ['suggestion', 'position'],  data: Task.type.put }},
                 "/tasks": {
                     get: { handler: Task.list }},
                 "/tips": {