Expand my Community achievements bar.

Learn about Edge Delivery Services in upcoming GEM session
SOLVED

Filter rejects: GET /bin/customservlet

Avatar

Level 2

Hi all,

We have a custom servlet which exposes content fragments as JSON. When we hit this servlet with custom domain we are getting "No resource found" error.

 

I have enabled dispatcher trace to debug and getting below error even after adding "allow" filter on GET method in customdomain_filter.any file. ({ /type "allow" /method "GET" /url "/bin/customservlet/*" }

 

[Thu Apr 29 04:43:12 2021] [D] [pid 20119 (tid 139831099217664)] request URL has no extension: /bin/customservlet/
[Thu Apr 29 04:43:12 2021] [D] [pid 20119 (tid 139831099217664)] cache-action for [/bin/customservlet/]: NONE
[Thu Apr 29 04:43:12 2021] [D] [pid 20119 (tid 139831099217664)] Filter rejects: GET /bin/customservlet/ HTTP/1.1

 

Also added below rule in custom rewrite file.

RewriteCond %{REQUEST_URI} ^/bin/customservlet
RewriteRule ^(.*)$ $1 [PT,QSA,NE,L]

 

When we hit the servlet with publish URL, we are seeing JSON output.

 

I'm guessing due to this filter reject error dispatcher is not able to connect to publisher and call the servlet.

 

However we have another  servlet exposing data as json and this is getting called without any errors. Compared filter and rewrite rules for both the servlets and they looks same.

 

Do we have to allow any other paths in the filter file or write any additional rules?

 

Any suggestions would help in resolving this error. Also how to enable debug level on rewrite rules?

 

Thanks.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @Antony6790 

 

If your servlet path is /bin/customservlet then you need to update the rule as below:

 

{ /type "allow" /method "GET" /url "/bin/customservlet*" } in filter.any

 

Also why you need this redirect? Any specific reason this redirect is applied?

RewriteCond %{REQUEST_URI} ^/bin/customservlet
RewriteRule ^(.*)$ $1 [PT,QSA,NE,L]

 

I see the request is being made as GET /bin/customservlet/ whereas it should be made as GET /bin/customservlet without a trailing slash.

 

What is the request URL you are making from dispatcher?

 

Please try by removing the redirect and it should work.

 

Thanks!

View solution in original post

4 Replies

Avatar

Correct answer by
Community Advisor

Hi @Antony6790 

 

If your servlet path is /bin/customservlet then you need to update the rule as below:

 

{ /type "allow" /method "GET" /url "/bin/customservlet*" } in filter.any

 

Also why you need this redirect? Any specific reason this redirect is applied?

RewriteCond %{REQUEST_URI} ^/bin/customservlet
RewriteRule ^(.*)$ $1 [PT,QSA,NE,L]

 

I see the request is being made as GET /bin/customservlet/ whereas it should be made as GET /bin/customservlet without a trailing slash.

 

What is the request URL you are making from dispatcher?

 

Please try by removing the redirect and it should work.

 

Thanks!

Avatar

Level 2
Thanks for the quick reply. Will remove the / in the filter and try again. I just used previous implementation for the rewrite rule. Even I don't think it's needed. Will check more on this tomorrow.

Avatar

Community Advisor
Also please remove the rewrite condition as mentioned above.

Avatar

Employee Advisor

Hi @Antony6790!

As @Asutosh_Jena_ already mentioned, the trailing slash may be an issue in your rule and the rewriting should not be necessary.

In addition to that, please review your full set of filter rules in the dispatcher configuration and make sure that there is no deny-rule placed after your servlet allow-rule and that the ID of your allow-rule is unique (the leading /0123 numbering if you're following the default pattern). Please note: the ID numbering of filter rules is not required to be a number nor is there any ordering based on the IDs. The dispatcher will evaluate the rules top to bottom as they appear in your filter definition file. The only requirement to the rule IDs is for them to be unique.

 

If this does not lead to success, you may want to (temporarily) remove other (deny-) rules one by one from the filter definition file until things work as expected as a debugging measure. This way you can identify other rules that interfere with your servlets allow-rule.

 

Hope that helps!