How does Cloudlet Edge Redirector and Property Manager Config rules precedence work?

Document created by Saurabh Deshpande on Aug 21, 2015
Version 1Show Document
  • View in full screen mode

If I have redirect rules configured in Edge Redirector Cloudlet and also in Property Manager Config which conflict with each other which rule takes precedence?
How does this affect if Origin is also having a redirect rule that conflicts with them?

 

Hi Saurabh,

 

I understand the question and why you are concerned.

 

Well, it depends a bit on the order of rules and behaviors in your Property Manager configuration. Without Edge Redirector the whole PM configuration file would be parsed with the last redirect rule (which applies to a particular request) taking effect.

 

If any redirect rule is applied then there is not going to be a forward request to the origin, so the origin redirect rules would not take effect.

 

However, if you consider a PM configuration which includes the Edge Redirector Cloudlet, the story is slightly different: Upon an incoming client request the Edge server starts parsing the PM configuration file - potentially including any (PM) redirect rules - until it reaches the place where the Edge Redirector behavior is enabled (given that it is used for the incoming request, as it might be under a match criteria to apply to certain requests only). If the Edge Redirector policy reaches a place where a redirect rule is applied it will stop parsing the remainder of the Edge Redirector policy (first match applies) and issue that redirect to the client.

 

David Theobald, Maya Bustan, Lukasz Czerpak, could you please confirm?

 

Best Regards,

Gunther

 

Yes, this is correct. Edge Redirector can be think of like pure redirection rule in Property Manager, so the order of PM rules matters. Within ER policy first matching rule wins. Also, Edge Redirectors cannot be daisy-chained.

 

Lukasz Czerpak is correct (like usual!).  The order of the behaviors in Property Manager still applies.  If there is a redirect found on the edge (either via a rule in Property Manager or in Edge Redirector Cloudlet), the edge will serve that result to the client and the origin will not be consulted at all.  If no rules on the edge exist or match the incoming request, the origin's redirect logic would kick in.

 

David,

 

now I would like to ask a last question about this topic: Imagine there is a redirect rule in PM itself (not the Cloudlet) and further down in the configuration the ER Cloudlet is enabled with a matching redirect rule as well - which redirect would take place, from PM or Cloudlet rule?

 

If it is the other way round - first there is the Cloudlet behavior with matching redirect rule, then further down in the PM configuration you have a PM redirect rule - I suppose the Cloudlet redirect rule applies. Is this correct?

 

Thanks, Gunther

 

now I would like to ask a last question about this topic: Imagine there is a redirect rule in PM itself (not the Cloudlet) and further down in the configuration the ER Cloudlet is enabled with a matching redirect rule as well - which redirect would take place, from PM or Cloudlet rule?

 

from Cloudlet

 

If it is the other way round - first there is the Cloudlet behavior with matching redirect rule, then further down in the PM configuration you have a PM redirect rule - I suppose the Cloudlet redirect rule applies. Is this correct?

 

No, PM redirect rule.

 

ER metadata are injected into the configuration at the same place where 'call-template' is invoked, so it's the same place where PM's rule is defined. It means that ER metadata and the configuration metadata are executed in the same context.

 

There can be more interesting scenarios but it all boils down to the rules of metadata execution. For example, the following metadata:

 

<edgeservices:redirect.generate.rule name="GROUP1">

    <response-code>302</response-code>

    <select-prefix>/</select-prefix>

    <destination>=http://%(AK_HOSTHEADER)/1/</destination>

    <status>on</status>

</edgeservices:redirect.generate.rule>

<edgeservices:redirect.generate.rule name="GROUP2">

    <response-code>302</response-code>

    <select-prefix>/</select-prefix>

    <destination>=http://%(AK_HOSTHEADER)/2/</destination>

    <status>on</status>

</edgeservices:redirect.generate.rule>

<edgeservices:redirect.generate.rule name="GROUP1">

    <response-code>302</response-code>

    <select-prefix>/</select-prefix>

    <destination>=http://%(AK_HOSTHEADER)/3/</destination>

    <status>on</status>

</edgeservices:redirect.generate.rule>

 

results in redirecting to '/2/' path. It's because redirect tag belonging to GROUP1 appears first and last redirection rule only overrides values. Redirection belonging to GROUP2 is newer and takes precedence.

 

ER doesn't use name attribute in redirect rule, PM use "generic_redirect" as per default but you can change it to "mobile_redirect". So if we have 2 PM redirect rules which matches and ER rules which also matches as follows:

 

PM rule (type: default): redirect to /1/

ER rule: redirect to /2/

PM rule (type: default): redirect to /3/

 

The result will be /2/. However if you change last PM rule to mobile type as follows

 

PM rule (type: default): redirect to /1/

ER rule: redirect to /2/

PM rule (type: mobile): redirect to /3/

 

you will get redirected to /3/.

 

+1

 

This document was generated from the following discussion: How does Cloudlet Edge Redirector and Property Manager Config rules precedence work?

Attachments

    Outcomes