Filter rejects: GET /bin/customservlet | Community
Skip to main content
A
Antony6790
Level 3
April 29, 2021
Solved

Filter rejects: GET /bin/customservlet

  • April 29, 2021
  • 2 replies
  • 1412 views

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.

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

    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!

    2 replies

    Asutosh_Jena_
    Community Advisor
    Asutosh_Jena_Community AdvisorAccepted solution
    Community Advisor
    April 29, 2021

    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!

      A
      Antony6790Author
      Level 3
      April 29, 2021
      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.
      MarkusBullaAdobe
      Adobe Employee
      MarkusBullaAdobeAdobe Employee
      Adobe Employee
      April 29, 2021

      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!

        Terms & ConditionsAccessibility statement

        Loading footer...