-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Set HEAD routes automatically for each GET route #2700
Conversation
Reading the issue it seems not necessary: the logic:
I would avoid this feature at this first step |
Thinking out loud:
|
|
In that case, it wouldn't be a semver major change. |
I strongly believe it should be the default, but introducing it in a semver minor disabled by default while allowing people to opt in and then flipping the default for the next major is probably a good path forward 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work!
fastify.js
Outdated
@@ -96,6 +96,7 @@ function fastify (options) { | |||
const requestIdLogLabel = options.requestIdLogLabel || 'reqId' | |||
const bodyLimit = options.bodyLimit || defaultInitOptions.bodyLimit | |||
const disableRequestLogging = options.disableRequestLogging || false | |||
const exposeHeadRoutes = options.exposeHeadRoutes != null ? options.exposeHeadRoutes : true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs docs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the default is false, we can land this as minor against master.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with both approaches, setting it as false
by default will require way fewer changes to the tests as most of them are broken because of the feature. Should we move forward with a minor version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for default to false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 124fa9e
I'll just need to adjust my PR to point to master
lib/route.js
Outdated
@@ -231,6 +234,15 @@ function buildRouting (options) { | |||
return | |||
} | |||
|
|||
// TODO: @MetCoder95 Implement hability for ignoring paths |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not on the principles of Fastify. There is no ignoring (and regexps, etc). We can support it in an ecapsulation-friendly way if we want to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, my bad! Actually, it's a leftover as I followed the suggestion of using a single-route/global flag to enable/disable the feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is missing a change to the TypeScript types.
It probably makes sense to update the change in #2685 as well to mention it is built in from version 3.x (whenever it lands), but needs to be enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
We have a policy that these are updated by those who know them. |
Co-authored-by: Simen Bekkhus <sbekkhus91@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'd need to add a test for the types changes.
lib/headRoute.js
Outdated
|
||
if (typeof payload.resume === 'function') { | ||
payload.on('error', (err) => { | ||
reply.log.error({ err, path: req.url }, 'Error on Stream found for HEAD route') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reply.log.error({ err, path: req.url }, 'Error on Stream found for HEAD route') | |
reply.log.error({ err }, 'Error on Stream found for HEAD route') |
Path is not needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, done in 130646d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
const { exposeHeadRoute } = opts | ||
const hasRouteExposeHeadRouteFlag = exposeHeadRoute != null | ||
const shouldExposeHead = hasRouteExposeHeadRouteFlag ? exposeHeadRoute : globalExposeHeadRoutes | ||
const headRouteExists = router.find('HEAD', path) != null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a thought: if there is a HEAD route and the user sets the route level option hasRouteExposeHeadRouteFlag
too, would it be too harsh logging a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think so, would be just adding an else if
to see if the headRouteExists
and hasRouteExposedHeadRouteFlag
it's set to true
for printing the warning. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could let users say "oh gosh, it saves me a bad headache"
If you have the chance to add it, I think it will be really appreciated by someone!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha, sure! No issue at all, I think will save someone's day, let me add it 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 976b080
Please have a look 🙂
Hi guys! Is there anything left I should take care of? |
Nothing, CI got stuck. |
I'm glad to see this addition. FWIW, HEAD and GET are required according to RFC-7231:
|
@metcoder95 I have a small question about this PR: fastifyApp.resgiter((fastify, opt) => {
fastify.route({
url: ...
exposeHeadRoutes: true // I get a TypeScript error here and when I bypass it using "as any" nothing happens
})
}) |
Hmm, the type for the route options has the |
The exposeHeadRoute (singular) is added to fastify options after updating to 3.14.2. Thanks. |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Closes #2619
Note
Open questions
Should be able to pass a global flag to deactivate the feature?Global and Route specific flags will be supportedShould be able to ignore specific routes (by RegExps or Strings)?DiscardedChecklist
npm run test
andnpm run benchmark
and the Code of conduct