serv/mox
1
0
Fork 0
mirror of https://github.com/mjl-/mox.git synced 2024-12-28 17:33:47 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions
mox/testdata/webserver/domains.conf

94 lines
2 KiB
Text
Raw Normal View History

improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
Domains:
mox.example:
LocalpartCaseSensitive: false
Accounts:
mjl:
Domain: mox.example
Destinations:
deprecate having only localparts in an Account's Destinations, it should always be a full email address current behaviour isn't intuitive. it's not great to have to attempt parsing the strings as both localpart and email address. so we deprecate the localpart-only behaviour. when we load the config file, and it has localpart-only Destinations keys, we'll change them to full addresses in memory. when an admin causes a write of domains.conf, it'll automatically be fixed. we log an error with a deprecated notice for each localpart-only destinations key. sometime in the future, we can remove the old localpart-only destination support. will be in the release notes then. also start keeping track of update notes that need to make it in the release notes of the next release. for issue #18
2023-03-10 00:07:37 +03:00
mjl@mox.example: nil
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
WebDomainRedirects:
redir.mox.example: mox.example
WebHandlers:
for WebRedirect, don't "match" when the destination URL has the same scheme,host,path, for doing http -> https redirects without loops you can already get most http to https redirects through DontRedirectPlainHTTP in WebHandler, but that needs handlers for all paths. now you can just set up a redirect for a domain and all its path to baseurl https://domain (leaving other webdirect fields empty). when the request comes in with plain http, the redirect to https is done. that next request will also evaluate the same redirect rule. but it will not cause a match because it would redirect to the same scheme,host,path. so next webhandlers get a chance to serve. also clarify in webhandlers docs that also account & admin built-in handlers run first. related to issue #16
2023-03-09 01:29:44 +03:00
-
LogName: redirhttps
Domain: schemeredir.example
PathRegexp: ^/
DontRedirectPlainHTTP: true
WebRedirect:
BaseURL: https://schemeredir.example
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
-
LogName: static
Domain: mox.example
PathRegexp: ^/static/
DontRedirectPlainHTTP: true
implement transparent gzip compression in the webserver we only compress if applicable (content-type indicates likely compressible), client supports it, response doesn't already have a content-encoding). for internal handlers, we always enable compression. for reverse proxied and static files, compression must be enabled per handler. for internal & reverse proxy handlers, we do streaming compression at "bestspeed" quality (probably level 1). for static files, we have a cache based on mtime with fixed max size, where we evict based on least recently used. we compress with the default level (more cpu, better ratio).
2023-08-21 22:52:35 +03:00
Compress: true
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
WebStatic:
# This is run from the http package.
implement transparent gzip compression in the webserver we only compress if applicable (content-type indicates likely compressible), client supports it, response doesn't already have a content-encoding). for internal handlers, we always enable compression. for reverse proxied and static files, compression must be enabled per handler. for internal & reverse proxy handlers, we do streaming compression at "bestspeed" quality (probably level 1). for static files, we have a cache based on mtime with fixed max size, where we evict based on least recently used. we compress with the default level (more cpu, better ratio).
2023-08-21 22:52:35 +03:00
Root: ../testdata/webserver
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
ListFiles: true
ResponseHeaders:
X-Test: mox
-
LogName: nolist
Domain: mox.example
PathRegexp: ^/nolist/
DontRedirectPlainHTTP: true
WebStatic:
StripPrefix: /nolist/
# This is run from the http package.
implement transparent gzip compression in the webserver we only compress if applicable (content-type indicates likely compressible), client supports it, response doesn't already have a content-encoding). for internal handlers, we always enable compression. for reverse proxied and static files, compression must be enabled per handler. for internal & reverse proxy handlers, we do streaming compression at "bestspeed" quality (probably level 1). for static files, we have a cache based on mtime with fixed max size, where we evict based on least recently used. we compress with the default level (more cpu, better ratio).
2023-08-21 22:52:35 +03:00
Root: ../testdata/webserver/static
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
-
LogName: httpsredir
Domain: mox.example
PathRegexp: ^/tls/
WebStatic:
# This is run from the http package.
implement transparent gzip compression in the webserver we only compress if applicable (content-type indicates likely compressible), client supports it, response doesn't already have a content-encoding). for internal handlers, we always enable compression. for reverse proxied and static files, compression must be enabled per handler. for internal & reverse proxy handlers, we do streaming compression at "bestspeed" quality (probably level 1). for static files, we have a cache based on mtime with fixed max size, where we evict based on least recently used. we compress with the default level (more cpu, better ratio).
2023-08-21 22:52:35 +03:00
Root: ../testdata/webserver/static
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config - make builtin http handlers serve on specific domains, such as for mta-sts, so e.g. /.well-known/mta-sts.txt isn't served on all domains. - add logging of a few more fields in access logging. - small tweaks/bug fixes in webserver request handling. - add config option for redirecting entire domains to another (common enough). - split httpserver metric into two: one for duration until writing header (i.e. performance of server), another for duration until full response is sent to client (i.e. performance as perceived by users). - add admin ui, a new page for managing the configs. after making changes and hitting "save", the changes take effect immediately. the page itself doesn't look very well-designed (many input fields, makes it look messy). i have an idea to improve it (explained in admin.html as todo) by making the layout look just like the config file. not urgent though. i've already changed my websites/webapps over. the idea of adding a webserver is to take away a (the) reason for folks to want to complicate their mox setup by running an other webserver on the same machine. i think the current webserver implementation can already serve most common use cases. with a few more tweaks (feedback needed!) we should be able to get to 95% of the use cases. the reverse proxy can take care of the remaining 5%. nevertheless, a next step is still to change the quickstart to make it easier for folks to run with an existing webserver, with existing tls certs/keys. that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
-
LogName: baseurlonly
Domain: mox.example
PathRegexp: ^/baseurl/
DontRedirectPlainHTTP: true
WebRedirect:
BaseURL: https://tls.mox.example?q=1#fragment
-
LogName: pathonly
Domain: mox.example
PathRegexp: ^/pathonly/
DontRedirectPlainHTTP: true
WebRedirect:
OrigPathRegexp: ^/pathonly/old/(.*)$
ReplacePath: /pathonly/new/$1
StatusCode: 307
-
LogName: baseurlpath
Domain: mox.example
PathRegexp: ^/baseurlpath/
DontRedirectPlainHTTP: true
WebRedirect:
BaseURL: //other.mox.example?q=1#fragment
OrigPathRegexp: ^/baseurlpath/old/(.*)$
ReplacePath: /baseurlpath/new/$1
# test code depends on these last two webhandlers being here.
-
LogName: strippath
Domain: mox.example
PathRegexp: ^/strip/
DontRedirectPlainHTTP: true
WebForward:
StripPath: true
# replaced while testing
URL: http://127.0.0.1:1/a
ResponseHeaders:
X-Test: mox
-
LogName: nostrippath
Domain: mox.example
PathRegexp: ^/nostrip/
DontRedirectPlainHTTP: true
WebForward:
# replaced while testing
URL: http://127.0.0.1:1/a
ResponseHeaders:
X-Test: mox
Reference in a new issue Copy permalink