Hi Jeremy, I would like to refer to bullet 2 in your proposal. Coupling between the xml_id and the host regexp, making the host regexp immutable may create undesired limitations. For example, if, for any reason, the content provider has to change the host regexp, she will have to create a new DS. This limitation prevents long term reports on DS volume, running long term analytics and other operations that you may want to run over long periods of time. In general, the host regexp is an attribute of the DS and therefore, unlike the id which should be immutable, I think it should be mutable, like any other attribute.
A side issue is that we would like to suggest promoting TC-55 <https://issues.apache.org/jira/browse/TC-55> <https://issues.apache.org/jira/browse/TC-55>in order to allow DS to be matched by a combination of host regexp and path regexp. TC-55 <https://issues.apache.org/jira/browse/TC-55> requires it should be allowed to have the same host regexp for different DS, using the path regexp as differentiator. This option has the benefit of using a single certificate for multiple DSs, it also reduces the complexity of delegating traffic between CDNs, like the use cases of CDNi and Open Caching. Unless I misunderstand the proposal, binding the first host regexp with the xml_id makes it impossible to have the same host for different DS, as required by TC-55 <https://issues.apache.org/jira/browse/TC-55>. Thanks, Ori On Thu, Apr 27, 2017 at 6:37 AM, Zhilin Huang (zhilhuan) <[email protected] > wrote: > Hi Jeremy, > > I like the idea that make xml_id and ds.regex at position 0 immutable. > Actually we have suffered some issues on HTTPs delivery services, and I had > ever created issue TC-187 with PR #360. > > Besides ds.regex at position 0, the ds.regex at other position of type > HOST_REGEXP is not working for HTTPs. I think the reason is SAN is no > supported in currently implementation in “generate_ssl_keys”. Do we have > any plan to support multiple subdomain for HTTPs? > > If we do plan to support SAN, I think we need also consider the > modification for ds.regex at position other than 0. > > > Thanks, > Zhilin > > > > On 4/27/17, 1:41 AM, "Jeremy Mitchell" <[email protected]> wrote: > > As we port functionality from the existing TO UI to the TO API, I am > always > looking for ways to simplify things. I can't lie. I like simple. Plus, > simple == less user error. I would like to discuss the possibility of > making changes to how xml_id works (at least thru the API). Here's > what I > propose. Feel free to poke holes in it. > > 1. make delivery service xml_id immutable. If you create a delivery > service > with xml_id = foo-bar, that is it. no changing it....ever... > 2. the ds.regex in position 0 must always be of type HOST_REGEXP and in > this format - .*\.xml_id\..* - this can be created for you when a > delivery > service is created and again, no changing this...ever...plus you don't > have > to fumble around with regex... > > I'm not 100% sure of all the problems associated with changing xml_id > on a > ds but I think there are a few. It can be done but I think you need to > know > what you're doing. And with self service coming down the pike? pipe? I > would be afraid to let users change xml_id... > > Regarding the ds.regex in position 0, this I know: > > A - it has to be in the format .*\.xml_id\..* (otherwise traffic router > barfs?) > B - it drives the dnssec keys for the ds (if the ds is in a dnssec > enabled > cdn) so changing it requires a deletion of existing dnssec keys and > creation of new ones > C - if you change it, you better generate new ssl certs if your ds is > https > > A and B can be done programattically but C cannot be. > > So back to my point. Why not simplify the whole process and make > ds.xml_id > and ds.regex at position 0 immutable and reduce the chance of users > shooting themself in the foot? > > One drawback I can think of: If xml_id=foo-bar, they are locked into > edge.foo-bar.cdn.domain.com which seems like an acceptable tradeoff > to me > as they can always add cnames if they don't like that URL. > > Thoughts? > > > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email protected]
