Ignore URL params| Does it work for a URL pattern as abc.html/1/def | Community
Skip to main content
S
sudhag73425455
Level 2
March 20, 2018

Ignore URL params| Does it work for a URL pattern as abc.html/1/def

  • March 20, 2018
  • 1 reply
  • 6182 views

Hello,

We have a URL pattern as below. The strings after the .html in below link are added by client side code - React Routes.

These strings after html are all dynamic and based on user's interaction with the application. There could be a maximum of 5 strings that can be added in the URL based on user's interaction.

..../guide/upfits/vehicle.html/2/abcdef/summary

Requirement is: Since the page vehicle.html does not change with the values of the strings we want the HTML to be cached in dispatcher. 

We have the ignoreURLParams in place which is as below.

Observation: No matter what values are passed after .html, the vehicle.html is returning from dispatcher once its cached the first time.

Question: Wanted to confirm that this is happening due to the ignoreURLParams. Since I thought for ignoreURLParams would only work for query strings like this ../vehicle.html?q=abc.   Does ignoreURLParams work for any string after.html or how does it exactly work? I searched online but could not find a convincing response.

/ignoreUrlParams

    {

/1001 { /glob "*" /type "allow" }

}

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
March 20, 2018

The dispatcher does not do URL decomposition like Sling does. The dispatcher does not know that in /guide/upfits/vehicle.html/2/abcdef/summary the "vehicle.html" is the actual file/resource which is requested.

I don't know anything about react routes, but if you want to have them cached for the dispatcher, you should adhere to a few rules:

* the requested URL should have an extension. /guide/upfits/vehicle.html/2/abcdef/summary has no extension, as the dispatcher considers the string as opaque and checks only the element after the last slash ("/") for an extension.

* "vehicle.html" can be a directory or a file, but not both. So either /guide/upfits/vehicle.html/2/abcdef/summary.html is cached (then vehicle.html is a directory) or /guide/upfits/vehicle.html is cached (as file). If something cannot get cached, it's requested from AEM. So you should design your URLs carefully if you want dispatcher caching working.

* I would recommend to implement these react routes as selectors (instead of suffix); then it's very unlikely that you have these issues mentioned above (or it is much easier to avoid them).

Jörg

    S
    sudhag73425455Author
    Level 2
    March 21, 2018

    I understand your points. I have 2 concerns now

    But on your #2, currently vehicle.html is cached as a file.

    Concern1 :  If dispatcher checks only the element after the last slash, how is that vehicle.html is getting cached as a file currently and subsequent requests are returned from dispatcher. It looks as if it is completely ignoring the strings after vehicle.html. How is that happening? No matter what strings I have after vehicle.html all of them are ignored and those requests are served from dispatcher. What is causing this to happen?

    Concern 2: Regarding the recommended URL pattern from AEM point of view - would this be appropriate? ../vehicle.html#/2/abcdef/summary?

    Since client side react routes API keeps adding these strings with a slash as a separator after the AEM vehicle.html file.

    Given that sling selectors would be the last option. Are there any other URL patterns that we can aim to build from FE side.

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      March 21, 2018

      Regarding Concern 1: With "they are returned from dispatcher" you mean that the dispatcher can handle these requests completely on its own and is not creating a request to AEM? I would doubt that, as the dispatcher only caches responses of GET requests with an extension.

      Regarding concern 2: the data after the anchor ("#") is not sent to the server, so no matter what comes after the anchor character, the dispatcher will always deliver the very same response.

      Jörg

        Terms & ConditionsAccessibility statement

        Loading footer...