Skip to content
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

Proposal: Upgrades to the Caddyfile #619

Closed
mholt opened this issue Feb 20, 2016 · 51 comments

Comments

Projects
None yet
@mholt
Copy link
Owner

commented Feb 20, 2016

A number of issues (#587, #566, #310, #167, #103, and maybe #584 and #209) and discussions in gitter chat have some things in common: they want to match requests by more than just the path prefix, and they want to be able to use variable or pre-defined values elsewhere in the Caddyfile.

In an attempt to mostly resolve most of those issues, I propose a few changes/upgrades to the Caddyfile.

1. More powerful path matching

Right now, most directives only accept a base path to match:

redir /foo https://sub.example.com/foo

If we replace /foo (the base path) with a more expressive matching block, we can meet most users' needs. For example:

redir {
    {path} not /
    and {>Referer} has google.com or {>Referer} has bing.com
} https://sub.example.com{uri}

Notice here that we've specified three conditions, where the last two are grouped because they are on the same line. We're using placeholders for the dynamic values. It is the equivalent of this pseudocode:

req.URL.Path != "/" && (strings.Contains(header["Referer"], "google.com") || strings.Contains(header["Referer"], "bing.com")

2. Virtual hosts defined by more than an explicit host:port

We've had numerous requests for variable site roots, but that's complicated since some directives need to know the site root when the server starts.

So how about we describe "virtual hosts" not so much as a host:port but as a "site" instead, and sites can be defined with wildcards and even request paths:

# What you're used to: a server block is headed by a host name
example.com {
    root /www/example.com
}

# But you could specify a path to have variable roots
example.com/foo {
    root /www/foo
}
example.com/bar {
    root /www/bar
}

# You could also use wildcards
# (but the *-value would not be accessible by a placeholder)
*.example.com {
    root /www/sub.example.com
}

However, if wildcards are used in a hostname, we are not able to issue certificates for those names. Even if Let's Encrypt enabled wildcard issuance, we wouldn't be able to issue certificates for example*.com, at least, not until Caddy gets On-Demand TLS (which issues certificates during the TLS handshake, about which I'm in talks with Let's Encrypt right now, hoping they'll let me do it).

3. Re-using blocks and arguments

There have been some requests for variables. I'd like to know more about why environment variables and current placeholders will not suffice. I feel strongly that once we introduce memory into the Caddyfile it creeps ever closer to a programming language, or at least some sort of interpreted script. I like it simplicity right now. A lot. That was kind of the point of making Caddy.

A note on philosophy

These proposed changes go slightly against my better judgment, since the Caddyfile encourages well-architected websites and web applications that use paths to clearly define content and behavior, rather than invoking the complexities of HTTP when it is avoidable by simply organizing resources by path rather than by creating all sorts of complex conditions. Frankly, if your web server behavior has to be scripted, you might as well just write one with a real programming language anyway and gain the full benefits of mature tools, a turing-complete language, etc.

These changes considerably raise the complexity of the config-related code, but it might be a net savings in the long run, rather than trying ad-hoc solutions. I also want to help grow Caddy's adoption rate. But know that at the moment, I'm disinclined to implement these changes unless I can be convinced this is the best way to go. Changes have to be in-line with the Caddy philosophy of simplicity and ease of use.

I'm not promising any of these changes but I wanted to funnel the discussion of all those issues into here. As such, I'm closing those issues but encourage you to reference them for historical purposes, so you can glean a richer understanding of the problems we're trying to solve.

When you reply here...

There are 3 topics in this one issue but all involve a near-complete rewrite in how we parse and execute the Caddyfile. Please be specific about which topic you're referring to (1, 2, or 3), and use inline quotes and proper formatting to preserve context. Thanks!

@jahands

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2016

Regarding 1 and 3:
Feels overly complex and out of scope for a webserver designed with simplicity in mind. I'm just imagining insane 300 line Caddyfiles coming out of this when people should really just be writing in a real programming language. Last thing we want to endorse is people doing "clever" things that are unreadable and hard to debug.

For 2: wildcards should wait until you sort things out with Lets Encrypt. But I do like this:

example.com/blog{
    root /www/blog
}
example.com/pricing {
    root /www/pricing
}

It's a nice way to have completely separate "sites" without needing to use subdomains (which some people prefer doing.)

@elithrar

This comment has been minimized.

Copy link

commented Feb 20, 2016

Agreed with @jacobhands.

  1. A lot of scope creep: implementing a DSL. I also have to wonder about the performance hit here since you're now parsing multiple parameters per request. Maybe expose it through a plugin architecture down the road (i.e. similar to nginx + Lua) but having simple, readable Caddyfiles should be a major goal.
  2. This looks OK. You would need to consider how to handle the case where a user defines www.example.com and *.example.com (priority based on config file order? specificity?) and the lack of wildcard certificates via Let's Encrypt (as @jacobhands infers).
  3. Similar to what I said re: no. 1. Provide default variables for headers, request & response parameters, etc. to enable shortcuts but don't allow custom variable bindings.
@twotwotwo

This comment has been minimized.

Copy link

commented Feb 21, 2016

Agree with @elithrar and @jacobhands that boolean conditions, arbitrary variables, and a bunch of match types has scope-creep risk.

In the past I had bad experience setting up routing with a fancy mini-language. I think the basic problem was that it was tempting to add a rule in the config language because they're quick to add, but over time you started to wish more was just in code because you know the quirks of your main language better than those of the DSL, and it's hard to understand your config because there are too many rules and they're terse, and you end up with routing split between config and regular code anyway (because you eventually ran into something config couldn't do, or you just tried to stop growing the config after some point). I was dealing with mod_rewrite, which is a weirder syntax than what you're proposing, but I think the basic problems would occur with even a really nice DSL.

I like @elithrar's idea of possibly eventually revisiting via some kind of plugin architecture. There are interpreters in Go (e.g. otto does a subset of JS), or dynamically loading user-written Go might be interesting.

One possible exception to avoiding fancy stuff is if there's something that Caddy can just do far better than user code could be expected to. If you have something to turn a text file of thousands of paths into some sort of trie that's trivial to do lookups in, or something like that, I can see the case for adding that in Caddy itself even if it's a little complication.

@jungle-boogie

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2016

But know that at the moment, I'm disinclined to implement these changes unless I can be convinced this is the best way to go. Changes have to be in-line with the Caddy philosophy of simplicity and ease of use.

I like hearing this. Sometimes you'll just have to say no.

@tgulacsi

This comment has been minimized.

Copy link

commented Feb 21, 2016

I agree with @jacobhands every point!

Don't make this nice simple Caddyfile a monster!

@abiosoft

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2016

Regarding 1

My proposal would be having a separate directive location to define such complex paths. That way it is more readable and any simple user do not need to bother themselves about it. It will have same if condition capabilities like rewrite currently does.

location foo {
    if {path} is `/foo`
    ...
}
location bar {
    if {path} is `/bar`
    ...
}

browse foo
redir bar http://mysite.xyz

If the path does not start with /, it is gonna be treated as a location.

Regarding 3

I am not in favour of Caddyfile variables. I think environment variables are enough.

@Depado

This comment has been minimized.

Copy link

commented Feb 21, 2016

Regarding 1 and 2

The @abiosoft's proposal about the location directive looks good. I think Caddy should stick to it's current Caddyfile architecture where the top line is only the domain, otherwise it will get quickly confusing when people will mix the two approaches in the same Caddyfile.

I'm in favor of the wildcard matching though, even if the LetsEncrypt foundation isn't delivering such certificates. It would allow people using wildcard certificates to switch fully from another webserver to Caddy. Currently that's the only thing that prevents me from switching all my wesbites to Caddy.

Regarding 3

I agree with @abiosoft and @jacobhands on that point.

@alexandreteles

This comment has been minimized.

Copy link

commented Feb 21, 2016

Regarding 1:

I actually liked that approach, but I think that we should write it the same way we write the rewrite to maintain the Caddyfile coherence. This should be really good:

redir {
    {path}    not /
    and       {>Referer} has google.com or {>Referer} has bing.com
    to        https://sub.example.com{uri}
}

I think that if conditionals will be avaiable on redir it should be avaiable on rewrite too. But I really preferer the @abiosoft proposal for that.

Regarding 2:

I'm in for wildcard matching even if LE never support it. The documentation should state, of course, that for wildcard matching the user should bring their own certificates. That way, we can cover the case where users actually want to use Caddy for all their sites and already have a wildcard certificate for what they need or can afford buying it for their projects, but keep using LE certs for other sites.

For what @elithrar has questioned, I think that we should take the Nginx way of doing it:

From their documentation:

When searching for a virtual server by name, if name matches more than one of the specified variants, e.g. both wildcard name and regular expression match, the first matching variant will be chosen, in the following order of precedence:

  1. exact name
  2. longest wildcard name starting with an asterisk, e.g. “*.example.org”
  3. longest wildcard name ending with an asterisk, e.g. “mail.*”
  4. first matching regular expression (in order of appearance in a configuration file)

Regarding 3:

I've posted on #548 a case where variables can actually help us. I think that having to setup environment variables to the system user running Caddy can be way more confusing, if not tricky, to the end user than having the ability to use variables directly in the Caddyfile, especially if the system user does not have a login shell nor a password. I agree that if we introduce scope on the variables we will considerably grow the complexity of the Caddyfile too, so I think that all variables can be globals.

In addition, the caddy documentation states that environment variables are only allowed in addresses and arguments and that placeholders only work on directives that support them, so, it can't actually take the place of variables.

If we had variables, we could do something like that in the Caddyfile:

set aws_access_key   'AWSAccessKeyId=MY_COOL_KEY';
set url_expires      'Expires=1141889120';
set url_signature    'Signature=G2lLQgG1d8L5irmYbkJi2hABT3D';
set url_full       '?{aws_access_key}&{url_expires}&{url_signature}';

And propagate it over all hosts using private S3 buckets to access static files.

Regarding a note on philosophy:

I think that the question about simplicity isn't if the user can or not write something complicated, but if he can achieve what he needs in a easy way. Power users will ever crave for more control about what the server is doing and this capability, if don't get in the front of the common user, should not be ignored.

@elithrar

This comment has been minimized.

Copy link

commented Feb 21, 2016

@alexandreteles Is there common use-case for Caddyfile variables that does not example putting access keys into a configuration file? Typically you would fill those in with template tags via your favorite config. mgmt. tool (e.g. Ansible) and not store them statically, but it's probably not a good example to set. Env. variables abstract that, which is why I think they are doubly-useful here.

I also think it's important to have an easy-to-understand API, and part of that comes from knowing when to limit API surface area. Some of these features may not 'get in the way' of a regular user, but they increase the density of documentation, add complexity and mental overhead.

RE: no 2.

I'd argue that nginx's method is not friendly. The reason I raised those questions is because I know the nginx rules on matching, and don't think they align with the easy-to-understand nature of a Caddyfile. If we wanted to be "Go" about it, I think first-match based on config file ordering (which is similar to how ServeMux matches) is a simplistic-but-understandable approach.

No exceptions: define a match above another and that match applies (so *.example.com before www.example.com would match first, if defined first)

@Depado

This comment has been minimized.

Copy link

commented Feb 21, 2016

Regarding 2

No exceptions: define a match above another and that match applies (so *.example.com before www.example.com would match first, if defined first)

I really think that could lead to some unexpected behavior or unclear ones. In the case you describe here, www.example.com will never be served. I think the order in which you define your domain names should not interefere with the way the webserver handles them. Because, for instance, if a user types www.example.com it would fall in the *.example.com wildcard pattern matching. I think that's why nginx defined it that way. And also because searching from a map is way faster than searching with regexp. (I'm no expert so I might be wrong, it's totally okay to destroy my argument hehe)

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Feb 21, 2016

Thanks for the feedback so far! Glad there is so much opinion about the Caddyfile.

@elithrar

A lot of scope creep: implementing a DSL. I also have to wonder about the performance hit here since you're now parsing multiple parameters per request. Maybe expose it through a plugin architecture down the road (i.e. similar to nginx + Lua) but having simple, readable Caddyfiles should be a major goal.

The advanced matching would only be invoked if the user specified it, but yes, it will add latency to a request. Probably negligible for most, but not extremely busy servers, especially if regexp are used. I'm not a huge fan of using Lua for configuration, though, either -- I'd like to keep Caddy in Go, including its addons.

I also think it's important to have an easy-to-understand API, and part of that comes from knowing when to limit API surface area. Some of these features may not 'get in the way' of a regular user, but they increase the density of documentation, add complexity and mental overhead.

Yes, this, this this. The more pages of documentation, the more intimidated a user will be. I love the intuitiveness of the Caddyfile as it currently stands. And for those with very complex needs, maybe Caddy isn't for you. Caddy is for those who want to get things done the right way, quickly and easily, without a lot of mental overhead. If your backend web app has a confusing architecture where paths don't make sense or there's a lot of exceptions to the rules, maybe ngnix is better suited to your purpose.

I say "you" and "your" but I mean everyone 😉

@twotwotwo

I like @elithrar's idea of possibly eventually revisiting via some kind of plugin architecture. There are interpreters in Go (e.g. otto does a subset of JS), or dynamically loading user-written Go might be interesting.

I think sticking to Go would be optimal for the user experience and reducing the cognitive load. If everything is in Go, it's that easy. And nothing has to be interpreted. The only barrier is compiling a plugin, but they're already programmers, so we can provide them tools like caddydev and caddyext (which might be combined before the end).

@abiosoft

My proposal would be having a separate directive location to define such complex paths. That way it is more readable and any simple user do not need to bother themselves about it. It will have same if condition capabilities like rewrite currently does.

This is useful, but I see two issues with it. First, is that it's basically an implementation of variables, but the variables can only describe 'locations' or matching requests to directives. Second, is that it is still an implementation of variables, which I'm not overly fond of at this point, for the reasons described above.

@alexandreteles

I actually liked that approach, but I think that we should write it the same way we write the rewrite to maintain the Caddyfile coherence.

This clutters the directives; makes it confusing what belongs to the directive and what is just used for matching paths. Rewrite is an experiment in that regard, and I don't want it to seep into all the directives, especially since the if conditions might not be placed on adjacent lines... just not a good idea, IMO, to mix directive properties ("sub-directives") with path matching as much as we can avoid it.

I'm in for wildcard matching even if LE never support it. The documentation should state, of course, that for wildcard matching the user should bring their own certificates. That way, we can cover the case where users actually want to use Caddy for all their sites and already have a wildcard certificate for what they need or can afford buying it for their projects, but keep using LE certs for other sites.

Yeah, I'm leaning toward this, since Caddy (on master) can issue certificates on-demand during TLS handshakes (assuming I can ease the worries of Let's Encrypt) for those "wildcard" cases. So technically this is not a problem, but just might be a slight inconvenience for the user to have to make that distinction.

In addition, the caddy documentation states that environment variables are only allowed in addresses and arguments and that placeholders only work on directives that support them, so, it can't actually take the place of variables.

Actually, environment variables can be used in just about any part of the Caddyfile regardless of the directive, and are not placeholders. They just share the same syntax for consistency.

And propagate it over all hosts using private S3 buckets to access static files.

This is precisely why environment variables exist. I'm going to suggest that we use them.

@elithrar

No exceptions: define a match above another and that match applies (so *.example.com before www.example.com would match first, if defined first)

I do love the simplicity and clearness of this approach, and I even fought for it in #114. But I think @Depado is right: if a user defines sites for *.example.com and another for www.example.com, then I think the more specific one (the one with "www") should have priority. This is not too hard to implement with a prefix tree. But we don't have to have rules as complex as nginx, necessarily, especially we don't have to support regular expressions.

So far then, I'm leaning toward not doing 1 and 3, but am considering implementing 2.

@faddat

This comment has been minimized.

Copy link

commented Mar 3, 2016

@mholt
Your judgement is pretty good. I can barely use Nginx. After a few months with Caddy I feel quite comfortable with the style of the Caddyfile, so I've got to recommend you go with your gut in terms of how Caddyfile functions.

Thanks for your hard work!

@dprandzioch

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2016

I have another take on this. I'm not sure if this does belong here but I hope you all are fine having me posting this here...

What do you think about exposing the CLI configuration parameters as properties within Caddyfile? So that the user is able to configure his letsencrypt email address, log- and pidfiles etc. directly within Caddyfile? This would make it much more easier to provide service scripts for running caddy at OS boot time.

@faddat

This comment has been minimized.

Copy link

commented Mar 6, 2016

What's the trouble with systemd and flags? Not saying that you're
wrong, but having perfectly fine luck with those myself at the moment.

On 03/06/2016 04:39 PM, David Prandzioch wrote:

I have another take on this, adressing upgrades to the Caddyfile...
What do you think about exposing the CLI configuration parameters as
properties within Caddyfile? So that the user is able to configure his
letsencrypt email address, log- and pidfiles etc. directly within
Caddyfile? This would make it much more easier to provide service
scripts for running caddy at OS boot time.


Reply to this email directly or view it on GitHub
#619 (comment).

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Mar 6, 2016

@dprandzioch Great suggestion/question, let me answer it and see if this makes sense.

The Caddyfile defines sites, and is purposefully scoped so that each "directive" belongs to a site. The CLI flags apply to the whole Caddy process, 'globally'. So flags do things like set default values and configure process-level settings like a log, PID file, etc.

I echo @faddat's question; what's the trouble with flags exactly?

@dprandzioch

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2016

@faddat/mholt: Theres generally no problem with systemd and flags but at least when providing init scripts by shipping caddy through the distributions' package manager it's just uncommon to have to customize it. Also this may lead to problems when updating the init script. Additionally there are way more init systems beside systemd.

@mholt I see your concerns. That's a problem. What about having a optional config file for global configuration purposes like the most servers provide - only easier?

@dprandzioch

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2016

If you think this does not make sense, it's ok for me. But I think having users to edit systemd services in order to configure your cert issuer email is strange and nothing a user should have to think about.

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Mar 6, 2016

@dprandzioch That -email flag just sets the default email address. The email can be configured per-site using the tls directive:

tls you@yours.com
@dprandzioch

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2016

Oh sorry :-) that was my fault. Then I'm fine with the current Solution.

Am 06.03.2016 um 15:28 schrieb Matt Holt notifications@github.com:

@dprandzioch That -email flag just sets the default email address. The email can be configured per-site using the tls directive:

tls you@yours.com

Reply to this email directly or view it on GitHub.

@faddat

This comment has been minimized.

Copy link

commented Mar 6, 2016

But I'm a masochist: I actually like systems!
On Mar 6, 2016 9:24 PM, "David Prandzioch" notifications@github.com wrote:

@faddat/mholt: Theres generally no problem with systemd and flags but at
least when providing init scripts by shipping caddy through the
distributions' package manager it's just uncommon to have to customize it.
Also this may lead to problems when updating the init script. Additionally
there are way more init systems beside systemd.

@mholt https://github.com/mholt I see your concerns. That's a problem.
What about having a optional config file for global configuration purposes
like the most servers provide - only easier?


Reply to this email directly or view it on GitHub
#619 (comment).

@jahands

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2016

Alright awesome! I certainly prefer keeping it simple.

@1lann

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2016

I agree with what's been proposed so far with wildcards.

Regarding shared blocks, I personally think that if you're going to make it so you can only have 1 shared block (2 matching blocks), you may as well have no blocks at all, as people who want more than 1 shared block will end up having to use import statements, and can be inconsistent if they use both. I'd rather stick with having a single clean way to achieve something, which is using imports which I'm already happy with.

One suggestion I do have would be to allow imports to another special block inside the same Caddyfile instead of a seperate file. This isn't completely necessary but I'd find it useful. Example syntax of what it would look like:

www.domain.com {
    import @common
    ...
}

@common {
    tls email@domain.com
    gzip
    ...
}
@mholt

This comment has been minimized.

Copy link
Owner Author

commented Mar 13, 2016

@1lann That's pretty good, actually. I'll consider that as well.

@abiosoft

This comment has been minimized.

Copy link
Collaborator

commented Mar 14, 2016

Regarding 1

Can there be some form of global config for directives. For example, the rewrite conditions are bunch of if conditions. If if can be made global so irrespective of the directive it can be used. So Caddy will override the middleware, translate and handle it before the middleware processes other configs.
E.g.

redir /mobile {
    if {>User-agent} is Android
}

@mholt mholt removed the help wanted label Mar 21, 2016

@SoreGums

This comment has been minimized.

Copy link

commented Mar 21, 2016

re point 3:

So having chatted with someone in gitter, nginx has full blown conditional config parser per request, this is particularly useful when wanting to cache wordpress with plugins.

See this rocket-nginx conf file:

  • able to set variables
  • then use that info later to populate headers or conditions on if statements

You can see how if the file exits and it is a GET request nginx will serve a static file and wordpress won't know anything about it, then the kernel gets involved keeping hot things in ram etc.

As of today (2016.03.21) the rocket-nginx.conf could be written as a caddy middleware and everything would just work, however having to do that for every instance of this sort of situation could get a bit tedious and reusing blocks and arguments could be pretty powerful as long as it is Fast Enough™

@henriquechehad

This comment has been minimized.

Copy link

commented Mar 31, 2016

+1

already started the codes?

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Mar 31, 2016

Yeah, working on this! Might be a couple more weeks.

@miekg

This comment has been minimized.

Copy link
Collaborator

commented Apr 13, 2016

Coming late to this thread, but I'm pondering this issue as well in CoreDNS.

(I also like the import @common syntax). My self I was pondering the following:

error stdout
logs stdout

www.domain.com {
    // inherits the above statements (unless overruled)
    ...
}

So you have some kind of global block.

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Apr 13, 2016

@miekg How do we know what is an address and what is a directive?

As a general rule, I've decided against implementing inheritance. The @common syntax isn't bad IMO, but... I wonder if it would ever conflict someday with a hypothetical email server configured by the Caddyfile. (In other words, distinguishing which of these: @common, @mysite.com is meant to be for email addresses, could be tricky.)

@miekg

This comment has been minimized.

Copy link
Collaborator

commented Apr 13, 2016

@mholt Good question. In CoreDNS I don't have that problem because without an address a CaddyCorefile does not make sense. But for Caddy this is different. I can totally live with @common

Regarding the use of @.. you could allow a directive in common blocks:

common {
   @common
    tls email@domain.com
    gzip
    ...
}
@mholt

This comment has been minimized.

Copy link
Owner Author

commented May 29, 2016

I'm closing this as "essentially completed" for now; Caddy 0.9 is a drastic shift in how we view the Caddyfile (without changing the syntax/structure at all).

Caddy 0.9 does implement the 2nd item which is having paths in site addresses.

Number 1 is basically out I think (for now?), and number 3 may diminish when Caddy gets an API. I'll mark this as deferred so we can revisit the idea later. Thanks for your input, everyone!

@alixaxel

This comment has been minimized.

Copy link

commented Jan 13, 2017

@mholt I think I have a scenario regarding the path matching that wouldn't be addressed by any of suggestions:

localhost:8080 {
    basicauth / u$ername pa$$word
    basicauth /index.html u$ername pa$$word

    proxy /api localhost:50600 {
    }
}

It's not possible to protect only the root and the index file without also protecting the /api endpoint.

Is there a workaround for this?

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Jan 13, 2017

Yes, structure your site so your URL paths make logical, hierarchical sense. Things that are in common should have a common base path. So if all items in / are to be protected, then you can just put them all in root of the site. But if /api is not to be protected and, say, /protected is, then you make a subdirectory to protect that folder.

The proxy directive has a except keyword to work around this in the way that you want, but basicauth doesn't.

Some of the ideas above would address your use case, but we did not implement them.

@alixaxel

This comment has been minimized.

Copy link

commented Jan 14, 2017

@mholt Yes, normally that's what I would do, but since this is an existing website being served by nginx I was trying to port only the HTTP server config without having to change the references in the code.

I guess the point I'm trying to make is that location-like blocks would add a great deal of flexibility to Caddy, providing a solution for these and other scenarios, but I understand that it may not be feasible to change all the existing directives to inherit this setting.

In this case, even if I would change the protected areas to be served under /admin instead of / for instance, the root would still be served - what that would be I have no idea... I love Caddy and I think the only way to make this work for my existing codebase and use Caddy is to have subdomain blocks that mimic location blocks, something like:

localhost.dev {
    redir http://admin.localhost.dev;
}

admin.localhost.dev {
    basicauth / u$ername pa$$word;
}

api.localhost.dev {
    proxy / localhost:50600;
}

It's not always easy to adapt existing codebases to these limitations though, specially in a team.

@thalesfsp

This comment has been minimized.

Copy link

commented Jan 16, 2017

When we will have:

# You could also use wildcards
# (but the *-value would not be accessible by a placeholder)
*.example.com {
}

Available? Working? @mholt
Thanks!

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Jan 16, 2017

@thalesfsp Already implemented.

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Jan 16, 2017

@alixaxel I'm not totally satisfied with things as they are, either. I hope Caddy 2.0 will have better request matching capabilities.

@stp-ip

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2017

@alixaxel the issue could be solved via an addition to basicauth. The ability to exclude paths from basicauth as suggested here: https://forum.caddyserver.com/t/whitelisting-possibility-with-basic-auth

@mholt mholt referenced this issue Nov 9, 2017

Closed

'if' statements for the HTTP Caddyfile #1948

2 of 11 tasks complete

@mholt mholt removed the deferred label Nov 9, 2017

@mholt

This comment has been minimized.

Copy link
Owner Author

commented Nov 9, 2017

Number 3 is being implemented in #1921 and Number 1 is being implemented in #1948. That wraps up this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.