Related open issues: #1, #42, #44, #56, #75, #80, #105, #110, #129, #164
Related closed issues: #35, #45, #53, #87, #90, #93, #107
fabio currently uses the urlprefix- tag prefix to identify routes. The format is limited to specifying a host/path prefix which makes it difficult to allow optional features for a given route. Issue #42 mentions an alternative syntax which provides more options but is still primarily focussed on prefixes.
consul issue 1107 mentions a revamp of the API to provide generic KV support for services but doesn't provide a timeline. However, one suggestion is something like RFC 1464 which is used to store arbitrary k/v data in DNS TXT records.
fabio could use this as follows which would provide a generic key/value config mechanism which can also be moved to something else later. Note that RFC 1464 uses the backtick for escaping the =, and the backtick itself.
This would allow a generic mechanism to add options to routes and protocols other than HTTP like TCP to be configured properly.
fabio key=value key=value key=value
e.g.
fabio uri=host/path
fabio uri=host/path proto=http,https
fabio uri=host/path log=true cors=true strip=/path
fabio addr=1.2.3.4:6789 proto=tcp
Several design questions come to mind:
- Should multiple prefixes be specified as a multiple
uri attributes in a single tag or as multiple tags?
The challenge here would be a length restriction in the tags but we could allow both multiple tags and multiple uri attributes to work around this.
- Should the protocol be specified separately or as part of the URL?
As part of the URL has the benefit of being familiar but will require duplication if a path should be exposed via HTTP and HTTPS but not WS. Therefore, uri=host/path proto=http,https might be more compact.
Another approach would be to use JSON but the quoting makes this more difficult.
Related open issues: #1, #42, #44, #56, #75, #80, #105, #110, #129, #164
Related closed issues: #35, #45, #53, #87, #90, #93, #107
fabio currently uses the
urlprefix-tag prefix to identify routes. The format is limited to specifying ahost/pathprefix which makes it difficult to allow optional features for a given route. Issue #42 mentions an alternative syntax which provides more options but is still primarily focussed on prefixes.consul issue 1107 mentions a revamp of the API to provide generic KV support for services but doesn't provide a timeline. However, one suggestion is something like RFC 1464 which is used to store arbitrary k/v data in DNS TXT records.
fabio could use this as follows which would provide a generic key/value config mechanism which can also be moved to something else later. Note that RFC 1464 uses the backtick for escaping the
=,This would allow a generic mechanism to add options to routes and protocols other than HTTP like TCP to be configured properly.
Several design questions come to mind:
uriattributes in a single tag or as multiple tags?The challenge here would be a length restriction in the tags but we could allow both multiple tags and multiple
uriattributes to work around this.As part of the URL has the benefit of being familiar but will require duplication if a path should be exposed via HTTP and HTTPS but not WS. Therefore,
uri=host/path proto=http,httpsmight be more compact.Another approach would be to use JSON but the quoting makes this more difficult.