Expand my Community achievements bar.

Get ready! An upgraded Experience League Community experience is coming in January.
SOLVED

AEM 6.5 AMS - After URL shortening, URL Query parameters getting lost, help with debugging please.

Avatar

Level 7

hi folks,

I've a weird problem whereby after implementing URL shortening, one of my sites loses the query parameters. When I do getParameter in the use POJO, it returns null.

 

keyword = getRequest().getParameter("q");

LOG.info("keyword=" + keyword); <= null

 

I still see the query parameter in the shortened url in the browser search bar. ( dev.xxxxxxx.com/search-page/q=findthis )  But the internal redirect in the dispatcher seems to be losing "q" (I guess) ....  /content/xxxx/us/en/search-page.html

 

I have been putting debug into the Dispatcher (rewrite:trace8)  to try figure out what is happening without much luck. The trace doesn't show up query parameters. I think it ignores them by default.  Here is an example


error_log:[] [rewrite:trace2] [] mod_rewrite.c(500): [client x.y.x.x] .... - - [dev.xxxxxxx.com/sid#..][rid#.../initial] forcing '/content/xxxx/us/en/search-page.html' to get passed through to next API URI-to-filename handler.

 

I have other websites with similar dispatcher configurations and they don't have this problem.  

 

I found this  in modsec_audit.log ( I'm not sure what that is).

modsec_audit.log:referer: https://dev.zzzzzz,com/search-page/?q=crownaz     <= this site query parameters are fine

 

modsec_audit.log:referer: https://dev.xxxxxxx.com/  <= this site query parameters disappear

 

Any debugging suggestions welcome.  I'd love to know why the query parameters don't seem to  be getting to the publisher for the one site ( but not the others.)

Is there a way of seeing the internal redirect to the publisher including query parameters if there any.

 

thanks FIona

1 Accepted Solution

Avatar

Correct answer by
Level 4

@fionas76543059 - 

Since QSA is enabled and the query string never reaches Dispatcher (even with rewrite trace), it’s being stripped upstream.

The difference in modsec_audit.log between the working and failing sites points to a WAF/ModSecurity or CDN rule at the host level. Comparing those configs should reveal what’s dropping the parameter.

Dispatcher rewrite logs don’t include query strings by default, which further supports this.

View solution in original post

6 Replies

Avatar

Level 7

By the way, there is no  MultiViews parameters in the dispatcher confs. Also I've put QSA everywhere...

Avatar

Level 7

You can customize logs to make it clearer if there is a query parameter.

I have done this and there is no query parameter in the dispatcher logs for my site.

Could it be  WAF rule or something else upstream that is throwing away the query parameter for the host ?

Any suggestions welcome.

Avatar

Community Advisor

you can always check the request.log from AEM publisher to see if the requested url are getting as query params to AEM publisher

Avatar

Correct answer by
Level 4

@fionas76543059 - 

Since QSA is enabled and the query string never reaches Dispatcher (even with rewrite trace), it’s being stripped upstream.

The difference in modsec_audit.log between the working and failing sites points to a WAF/ModSecurity or CDN rule at the host level. Comparing those configs should reveal what’s dropping the parameter.

Dispatcher rewrite logs don’t include query strings by default, which further supports this.

Avatar

Level 2

As per your message,

"dev.xxxxxxx.com/search-page/q=findthis" 
-seems there is a typo and you have accidently appended query as <url>/q=findThis rather than using <url>?q=<findThis>.

url with https://<url>/q=<findThis> or https://<url>/?q=crownaz is treadted as a normal url by Apache.

Your  modsec_audit.log shows the same - rer: https://dev.zzzzzz,com/search-page/?q=crownaz

/search-page/q=findthis is not a query parameter from apache's stand point

 

To make it work either update your dispatcher rules to make the  /search-page/q=findthis to /search-page?q=findthis  and it will work. 
If due to some reason you can not update the dispatcher rule then update your POJO to something like this

 

String uri = request.getRequestURI();

if (uri.contains("/q=")) {
    String keyword = uri.substring(uri.indexOf("/q=") + 3);
}


I recommed updating dispatcher. It's easy, clean and global for entire project

 

 

Thanks all for your replies, the problem was indeed upstream of me.

And nothing to do with url rewriting ...