Great feedback. It sounds like people are OK with making xml_id immutable on a delivery service... but not so much about making the host header regex at position 0 immutable (the regex that requires this format - .*\xml-id\..*).
Just to revisit: You create a delivery service with xml_id=foo-bar and by default you get a host header regex in this format at position 0 - .*\xml-id\..* so you end up with URL=edge|tr.foo-bar.cdn.domain.com Maybe you're happy with that and life is good. Maybe you decide you want your URL to be edge| tr.something-else.cdn.domain.com instead.....so you need the ability to edit the host header regex at position 0 to .*\something-else\..* What about this? You can attach Static DNS entries to a delivery service. Can Static DNS entries be used to accomplish this use case while leaving .*\xml-id\..* alone? (Elsloo keyed me into that possibility) Jeremy On Fri, Apr 28, 2017 at 9:44 AM, Dave Neuman <neu...@apache.org> wrote: > I don't think we should be forcing users into using their xml_id as the > host_regex used to create the delivery URL. I think we can offer to create > it for them, but we should also let users have the ability to define what > their regex needs to be when they create their delivery service. We have > instances in our environment where the host regex does not match the xml_id > a delivery service and I don't think we should take that functionality > away. > You are correct, changing an xml_id or a host_regex could have unintended > consequences in the system, but I agree with Ori that not letting users > change it can cause other problems. I think we should allow users to > change it but maybe we need to figure out a way to only allow "super > special advanced" users to do it. > > --Dave > > On Thu, Apr 27, 2017 at 6:40 AM, Ori Finkelman <o...@qwilt.com> wrote: > > > 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) < > > zhilh...@cisco.com > > > 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" <mitchell...@apache.org> 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 | > > o...@qwilt.com > > >
