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?
    

Reply via email to