fastify / fastify-url-data

A plugin to provide access to the raw URL components

@fastify/url-data

A plugin for Fastify that adds support for getting raw URL information from the request.

Example

const fastify = require('fastify')()

fastify.register(require('@fastify/url-data'))

fastify.get('/foo', (req, reply) => {
  const urlData = req.urlData()
  req.log.info(urlData.path) // '/foo'
  req.log.info(urlData.query) // 'a=b&c=d'
  req.log.info(urlData.host) // '127.0.0.1'
  req.log.info(urlData.port) // 8080

  // if you just need single data:
  req.log.info(req.urlData('path')) // '/foo'

  reply.send({hello: 'world'})
})

// GET: 'http://127.0.0.1:8080/foo?a=b&c=d

License

Licensed under MIT

fastify-url-data's Issues

multiple register

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

We should check with fastify.hasDecorator() before adding the decorator.

so the user may register the plugin multiple times without issue.

Idea from: fastify/fastify-http-proxy#205

Motivation

No response

Example

No response

Remove Node core warning

🐛 Bug Report

A clear and concise description of what the bug is.

To Reproduce

Running npm test shows:

(node:61289) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.

Expected behavior

no warning

TypeScript-support: error TS2339: Property 'urlData' does not exist on type 'FastifyRequest<

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the issue has not already been raised

Issue

Writing code with types like

        handler:  async (req: FastifyRequest, reply: FastifyReply) => {
            const urlData = req.urlData()

won't compile with TypeScript because of the following error:

error TS2339: Property 'urlData' does not exist on type 'FastifyRequest<RouteGenericInterface, RawServerDefault, IncomingMessage, FastifySchema, FastifyTypeProviderDefault, unknown, FastifyBaseLogger, ResolveFastifyRequestType<...>>

When I remove the type FastifyRequest, it works:

handler:  async (req, reply: FastifyReply) => {
    console.log(req.urlData)

I have seen in the source-code and the issues (#2 (comment)), that this plugin is enhancing the FastifyRequest-interface with the urlData-property.
However, I can not make it to work somehow.

What is the correct approach, to use TypeScript and make urlData available in FastifyRequest interface?

TypeScript error: Property 'urlData' does not exist on type 'FastifyRequest'.

In my route:

fastify.get('/', async (request, reply) => {
  const urlData = request.urlData()
  ...
})

TypeScript would complain:

src/app.ts(55,26): error TS2339: Property 'urlData' does not exist on type 'FastifyRequest'.

because there is no attribute urlData on FastifyRequest: https://github.com/fastify/fastify/blob/master/fastify.d.ts#L22

v3.1.0 moved types to fastify-url-data-deprecated but doesn't re-export them and breaks existing installs

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

3.29.0

Plugin version

3.1.0

Node.js version

12.22.7

Operating system

macOS

Operating system version (i.e. 20.04, 11.3, 10)

12.3

Description

I updated url-data to 3.1.0 and had some typescript errors and noticed it doesn't include types. it looks like they were moved to fastify-url-data-deprecated, but not re-exported.

the solution seems to be to update to @fastify/... which -- from reading through the fastify issue on module plans -- seems like it should be a non-breaking major? is bumping to v4 the recommended approach?

Steps to Reproduce

npm i [email protected]

Expected Behavior

No response

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all 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 Travis CI, 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 delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

An in-range update of fastify is breaking the build 🚨

The devDependency fastify was updated from 2.11.0 to 2.12.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

fastify is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

Release Notes for v2.12.0

📚 PR:

• fix: skip serialization for json string (#1937)
• Added fastify-casl to Community Plugins (#1977)
• feature: added validation context to validation result (#1915)
• ESM support (#1984)
• fix: adjust hooks body null (#1991)
• Added mcollina's plugin "fastify-secure-session" (#1999)
• Add fastify-typeorm-plugin to community plugins (#1998)
• Remove Azure Pipelines (#1985)
• Update validation docs (#1994)
• Drop Windows-latest and Node 6 from CI as its failing. (#2002)
• doc: fix esm-support anchor (#2001)
• Docs(Fluent-Schema.md): fix fluent schema repo link (#2007)
• fix - docs - hooks - error handling (#2000)
• add fastify-explorer to ecosystem (#2003)
• Add a recommendations doc (#1997)
• Fix TOC typo in recommendations (#2009)
• docs(Typescript): typo (#2016)
• docs: fix onResponse parameter (#2020)
• Update template bug.md (#2025)
• fix replace way enum (#2026)
• docs: update inject features (#2029)
• Update Copyright Year to 2020 (#2031)
• add generic to typescript Reply.send payload (#2032)
• Shorten longest line (docs) (#2035)
• docs: OpenJS CoC (#2033)
• Workaround for using one schema for multiple routes (#2044)
• docs: inject chainable methods (#1917) (#2043)
• http2: handle graceful close (#2050)
• chore(package): update fluent-schema to version 0.10.0 (#2057)
• chore(package): update yup to version 0.28.1 (#2059)
• Update README.md (#2064)
• Added fastify-response-validation to ecosystem (#2063)
• fix: use opts of onRoute hook (#2060)
• Fixed documentation typo (#2067)
• Add missing TS definition for ServerOptions.genReqId function arg (#2076)
• fix: throw hooks promise rejection (#2070) (#2074)
• Add docs to stop processing hooks with async (#2079)

Commits

The new version differs by 38 commits.

• 7a37924 Bumped v2.12.0
• aacefcd Add docs to stop processing hooks with async (#2079)
• c052c21 fix: throw hooks promise rejection (#2070) (#2074)
• 6b39870 Add missing TS definition for ServerOptions.genReqId function arg (#2076)
• 7fa4bdd Fixed documentation typo (#2067)
• 6b73e0a fix: use opts of onRoute hook (#2060)
• 7bb9733 Added fastify-response-validation to ecosystem (#2063)
• 0a1c1f0 Update README.md (#2064)
• bd9f608 chore(package): update yup to version 0.28.1 (#2059)
• e19d078 chore(package): update fluent-schema to version 0.10.0 (#2057)
• d0c976e http2: handle graceful close (#2050)
• af8a6ac docs: inject chainable methods (#1917) (#2043)
• 62f21b1 Workaround for using one schema for multiple routes (#2044)
• 5258f42 docs: OpenJS CoC (#2033)
• ac46905 Shorten longest line (docs) (#2035)

There are 38 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all 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 Travis CI, 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 delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Remove greenkeeper from README

As titled

Http2 Support

Are there any plans to support Http2?

Currently, request.urlData() looks like the following when using http2

{ scheme: undefined, userinfo: undefined, host: 'undefined', port: undefined, path: '/', query: 'foo=bar', fragment: undefined, reference: 'relative' }

Issue v5 release

The next branch should be ready for issuing a release to coincide with fastify@5.

use `new URL` instead of `fast-uri`

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

For the purposes of this plugin, using the built-in new URL seems to be a better choice as it is now faster than fast-uri for parsing URLs

Motivation

No response

Example

No response

Should be using @fastify/fast-uri instead of uri-js

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

I think we should be using https://github.com/fastify/fast-uri instead of https://github.com/garycourt/uri-js

• fast-uri is faster than uri-js
• fast-uri is maintained by fastify

I'd be more than happy to submit a PR if this is wanted. Seems fairly easy looks like they use a compatible API.

Thanks!

Motivation

No response

Example

No response

Is there any reason why does it use urijs instead of native URL?

🚀 Feature Proposal

Remove dependency on urijs and use new URL() instead

Motivation

It should be faster and have 0 dependencies

X-Forwarded-Host is not used even when trustProxy is set on fastify server

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

4.x.x

Plugin version

No response

Node.js version

18.x

Operating system

Linux

Operating system version (i.e. 20.04, 11.3, 10)

Any

Description

@fastify/url-data does not use X-Forwarded-Host header when composing request URL and instead only uses Host header. This could cause issues for applications behind a reverse proxy, for example, NGINX by default will rewrite Host header to the host set in the proxy_pass directive.

Fastify will set req.hostname to the value of X-Forwarded-Host header when trustProxy option is set to true, and falls back to Host header otherwise.

I would be more than happy to submit a PR.

Possible solution

In the source for fastify-url-data the host is retrieved using

const host = this.headers[':authority'] || this.headers.host

I believe we can instead use

const host = this.hostname

This would keep the implementation of hostname consistent with fastify

The implementation in fastify for hostname is as follows link

if (this.ip !== undefined && this.headers['x-forwarded-host']) {
  return getLastEntryInMultiHeaderValue(this.headers['x-forwarded-host'])
}
return this.headers.host || this.headers[':authority']

Steps to Reproduce

const fastify = require('fastify')

const app = fastify({ trustProxy: true })

app.register(require('@fastify/url-data'))

app.get('/', async (req) => {
  const urlData = req.urlData()

  console.log('headers: ', req.headers)
  console.log('url-data host:', urlData.host)
  console.log('fastify hostname: ', req.hostname)
})

app.inject({
  url: '/',
  headers: {
    Host: 'internal.example.com',
    'X-Forwarded-Host': 'example.com',
  },
})

Output:

headers:  {
  host: 'internal.example.com',
  'x-forwarded-host': 'example.com',
  'user-agent': 'lightMyRequest'
}
url-data host: internal.example.com
fastify hostname:  example.com

Expected Behavior

Behaviour for setting hostname should be consistent with fastify server.