-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
httpcaddyfile: Add RegisterDirectiveOrder
function for plugin authors
#5865
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dunglas
reviewed
Oct 7, 2023
dunglas
approved these changes
Oct 7, 2023
francislavoie
force-pushed
the
plugin-directive-order
branch
from
February 23, 2024 20:54
af5bfc2
to
6c0bc3a
Compare
mholt
requested changes
Mar 5, 2024
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.
Thanks, this is quite a limited function but it sounds like some people will still find it useful -- we can try it! But I do want to mark it as experimental for now.
francislavoie
force-pushed
the
plugin-directive-order
branch
from
March 5, 2024 19:28
d45b370
to
7099750
Compare
mholt
approved these changes
Mar 6, 2024
francislavoie
force-pushed
the
plugin-directive-order
branch
from
March 6, 2024 19:36
7099750
to
5931d1f
Compare
dev-polymer
pushed a commit
to dev-polymer/caddy
that referenced
this pull request
Mar 13, 2024
…rs (caddyserver#5865) * httpcaddyfile: Add `RegisterDirectiveOrder` function for plugin authors * Set up Positional enum * Linter doesn't like a switch on an enum with default * Update caddyconfig/httpcaddyfile/directives.go Co-authored-by: Matt Holt <[email protected]> --------- Co-authored-by: Matt Holt <[email protected]>
This was referenced May 31, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We (@mholt @dunglas and I) were talking in Slack about the ergonomics of using the Caddyfile for end-users of custom builds of Caddy which may include many handler plugins. Forcing users to specify
order
or wrap things inroute
causes some friction that would be nice to smooth out.The reason we never did this in the past is because we didn't want to allow plugins to depend upon eachother, because we can't guarantee the order in which plugins are loaded. We also didn't want the ordering to become unreliable when the order of directives in the standard distribution changes.
We can mitigate those factors by doing two things:
defaultDirectiveOrder
which doesn't change, to ensure this, and modifydirectiveOrder
accordingly)order
global option allows) to reduce the chance of ordering that doesn't make sense.The API looks like this:
Or course, there's still a slight problem if two plugins try to both order the same way in relation to a standard directive (e.g. both are "before headers") because their order will not be guaranteed. There are some complicated ways we could mitigate this though, for example we could invalidate the ordering for both directives since they're in conflict, forcing the user to specify their own order for both. But ultimately I think this it probably not an immediate need, and we can expand upon that later.