# Class: RoutingContext

## vertx-web-js/routing_context~ RoutingContext

#### new RoutingContext()

  Represents the context for the handling of a request in Vert.x-Web.

  A new instance is created for each HTTP request that is received in the

  Source:
    - routing_context.js, line 39

### Methods

#### addBodyEndHandler(handler) → {number}

  Add a handler that will be called just before the response body has been completely written. This gives you a hook where you can write any extra data to the response before it has ended when it will be too late.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `handler` | function | the handler

  Source:
    - routing_context.js, line 452

  ##### Returns:

  the id of the handler. This can be used if you later want to remove the handler.
  Type
    number

#### addCookie(cookie) → {RoutingContext}

  Add a cookie. This will be sent back to the client in the response. The context must have first been routed to a CookieHandler for this to work.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `cookie` | Cookie | the cookie

  Source:
    - routing_context.js, line 232

  ##### Returns:

  a reference to this, so the API can be used fluently
  Type
    RoutingContext

#### addHeadersEndHandler(handler) → {number}

  Add a handler that will be called just before headers are written to the response. This gives you a hook where you can write any extra headers before the response has been written when it will be too late. The handler will be passed a future, when you've completed the work you want to do you should complete (or fail) the future. This can be done after the handler has returned.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `handler` | function | the handler

  Source:
    - routing_context.js, line 421

  ##### Returns:

  the id of the handler. This can be used if you later want to remove the handler.
  Type
    number

#### clearUser()

  Clear the current user object in the context. This usually is used for implementing a log out feature, since the current user is unbounded from the routing context.
  Source:
    - routing_context.js, line 533

#### cookieCount() → {number}

  Source:
    - routing_context.js, line 263

  ##### Returns:

  - the number of cookies. The context must have first been routed to a CookieHandler for this to work.
  - Type
      number

#### cookies() → {Array.<Cookie>}

  Source:
    - routing_context.js, line 278

  ##### Returns:

  - a set of all the cookies. The context must have first been routed to a CookieHandler for this to be populated.
  - Type
      Array.<Cookie>

#### currentRoute() → {Route}

  Source:
    - routing_context.js, line 178

  ##### Returns:

  - the current route this context is being routed through.
  - Type
      Route

#### fail(statusCode)

  Fail the context with the specified status code.

  This will cause the router to route the context to any matching failure handlers for the request. If no failure handlers match a default failure response will be sent.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `statusCode` | number | the HTTP status code

  Source:
    - routing_context.js, line 105

#### failed() → {boolean}

  Source:
    - routing_context.js, line 480

  ##### Returns:

  - true if the context is being routed to failure handlers.
  - Type
      boolean

#### fileUploads() → {Array.<FileUpload>}

  Source:
    - routing_context.js, line 340

  ##### Returns:

  - a set of fileuploads (if any) for the request. The context must have first been routed to a BodyHandler for this to work.
  - Type
      Array.<FileUpload>

#### get(key) → {Object}

  Get some data from the context. The data is available in any handlers that receive the context.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `key` | string | the key for the data

  Source:
    - routing_context.js, line 135

  ##### Returns:

  the data
  Type
    Object

#### getAcceptableContentType() → {string}

  If the route specifies produces matches, e.g. produces `text/html` and `text/plain`, and the `accept` header matches one or more of these then this returns the most acceptable match.
  Source:
    - routing_context.js, line 404

  ##### Returns:

  the most acceptable content type.
  Type
    string

#### getBody() → {Buffer}

  Source:
    - routing_context.js, line 325

  ##### Returns:

  - Get the entire HTTP request body as a Buffer. The context must have first been routed to a BodyHandler for this to be populated.
  - Type
      Buffer

#### getBodyAsJson() → {Object}

  Source:
    - routing_context.js, line 310

  ##### Returns:

  - Get the entire HTTP request body as a JsonObject. The context must have first been routed to a BodyHandler for this to be populated.
  - Type
      Object

#### getBodyAsString(encoding) → {string}

  Get the entire HTTP request body as a string, assuming the specified encoding. The context must have first been routed to a BodyHandler for this to be populated.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `encoding` | string | the encoding, e.g. "UTF-16"

  Source:
    - routing_context.js, line 293

  ##### Returns:

  the body
  Type
    string

#### getCookie(name) → {Cookie}

  Get the cookie with the specified name. The context must have first been routed to a CookieHandler for this to work.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `name` | string | the cookie name

  Source:
    - routing_context.js, line 217

  ##### Returns:

  the cookie
  Type
    Cookie

#### mountPoint() → {string}

  Source:
    - routing_context.js, line 164

  ##### Returns:

  - the mount point for this router. It will be null for a top level router. For a sub-router it will be the path at which the subrouter was mounted.
  - Type
      string

#### next()

  Tell the router to route this context to the next matching route (if any). This method, if called, does not need to be called during the execution of the handler, it can be called some arbitrary time later, if required.

  If next is not called for a handler then the handler should make sure it ends the response or no response will be sent.

  Source:
    - routing_context.js, line 89

#### normalisedPath() → {string}

  Return the normalised path for the request.

  The normalised path is where the URI path has been decoded, i.e. any unicode or other illegal URL characters that were encoded in the original URL with `%` will be returned to their original form. E.g. `%20` will revert to a space. Also `+` reverts to a space in a query.

  The normalised path will also not contain any `..` character sequences to prevent resources being accessed outside of the permitted area.

  It's recommended to always use the normalised path as opposed to HttpServerRequest#path if accessing server resources requested by a client.

  Source:
    - routing_context.js, line 202

  ##### Returns:

  the normalised path
  Type
    string

#### put(key, obj) → {RoutingContext}

  Put some arbitrary data in the context. This will be available in any handlers that receive the context.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `key` | string | the key for the data
  `obj` | Object | the data

  Source:
    - routing_context.js, line 120

  ##### Returns:

  a reference to this, so the API can be used fluently
  Type
    RoutingContext

#### removeBodyEndHandler(handlerID) → {boolean}

  Remove a body end handler

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `handlerID` | number | the id as returned from RoutingContext#addBodyEndHandler.

  Source:
    - routing_context.js, line 466

  ##### Returns:

  true if the handler existed and was removed, false otherwise
  Type
    boolean

#### removeCookie(name) → {Cookie}

  Remove a cookie. The context must have first been routed to a CookieHandler for this to work.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `name` | string | the name of the cookie

  Source:
    - routing_context.js, line 248

  ##### Returns:

  the cookie, if it existed, or null
  Type
    Cookie

#### removeHeadersEndHandler(handlerID) → {boolean}

  Remove a headers end handler

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `handlerID` | number | the id as returned from RoutingContext#addHeadersEndHandler.

  Source:
    - routing_context.js, line 437

  ##### Returns:

  true if the handler existed and was removed, false otherwise
  Type
    boolean

#### request() → {HttpServerRequest}

  Source:
    - routing_context.js, line 51

  ##### Returns:

  - the HTTP request object
  - Type
      HttpServerRequest

#### response() → {HttpServerResponse}

  Source:
    - routing_context.js, line 68

  ##### Returns:

  - the HTTP response object
  - Type
      HttpServerResponse

#### session() → {Session}

  Get the session. The context must have first been routed to a SessionHandler for this to be populated. Sessions live for a browser session, and are maintained by session cookies.
  Source:
    - routing_context.js, line 356

  ##### Returns:

  the session.
  Type
    Session

#### setAcceptableContentType(contentType)

  Set the acceptable content type. Used by

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `contentType` | string | the content type

  Source:
    - routing_context.js, line 546

#### setBody(body)

  Set the body. Used by the BodyHandler. You will not normally call this method.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `body` | Buffer | the body

  Source:
    - routing_context.js, line 493

#### setSession(session)

  Set the session. Used by the SessionHandler. You will not normally call this method.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `session` | Session | the session

  Source:
    - routing_context.js, line 506

#### setUser(user)

  Set the user. Usually used by auth handlers to inject a User. You will not normally call this method.

  ##### Parameters:

  Name | Type | Description
  --- | --- | ---
  `user` | User | the user

  Source:
    - routing_context.js, line 519

#### statusCode() → {number}

  If the context is being routed to failure handlers after a failure has been triggered by calling RoutingContext#fail then this will return that status code. It can be used by failure handlers to render a response, e.g. create a failure response page.
  Source:
    - routing_context.js, line 386

  ##### Returns:

  the status code used when signalling failure
  Type
    number

#### user() → {User}

  Get the authenticated user (if any). This will usually be injected by an auth handler if authentication if successful.
  Source:
    - routing_context.js, line 370

  ##### Returns:

  the user, or null if the current user is not authenticated.
  Type
    User

#### vertx() → {Vertx}

  Source:
    - routing_context.js, line 149

  ##### Returns:

  - the Vert.x instance associated to the initiating Router for this context
  - Type
      Vertx