aemaacs publish post servlet call fails with 404 error | Community
Skip to main content
H
helloosuman
Level 2
May 15, 2026
Solved

aemaacs publish post servlet call fails with 404 error

  • May 15, 2026
  • 5 replies
  • 109 views

aemaacs author post custom servlet call from a site content page works fine. But, publish post custom servlet call fails with 404 error.

When servlet with post request is getting called, I don't find any entry in publish access.log, error.log and request.log.

However, getting following entry in cdn.log {"timestamp":"2026-05-14T17:06:53+0000","ttfb":8,"ttlb":8,"cli_ip":"192.223.233.218","cli_country":"US","cli_region":"US-TX","rid":"some value","req_ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","aem_envKind":"SKYLINE","aem_tenant":"company name","host":"publish-p170552-e1826604.adobeaemcloud.com","url":"/bin/customservlet","method":"POST","res_ctype":"text/html; charset=iso-8859-1","cache":"PASS","debug":"","res_age":"","status":301,"pop":"IAD","rules":"","alerts":"","sample":"","ddos":false}

    Best answer by helloosuman

    ​@akhil_merupula ​@avesh_narang  it started working with following changes:

    RewriteCond %{REQUEST_URI} !^/bin/jiraapi/createTicket     RewriteRule ^([^.]*[^./])$ https://${MYGPS_HOST}$1.html [R=301,L]

    Order of above is very important though.

    5 replies

    A
    akhil_merupula
    Level 4
    May 15, 2026

    Hi ​@helloosuman ,

     

    The CDN log entry you shared is actually very revealing the fact that the request appears in cdn.log but not in publish access.log, error.log, or request.log tells us the request is being stopped before it reaches the publish instance entirely. This is not a servlet registration issue.

     

    A few things to check based on your CDN log:

     

    1. Dispatcher filter rules blocking POST to /bin/*
    This is the most common cause. AEMaaCS Dispatcher blocks POST requests to /bin/ paths by default. Check your dispatcher/src/conf.dispatcher.d/filters/filters.any file for rules like:

    /0001 { /type "deny" /method "POST" /url "/bin/*" }

    You need an explicit allow rule before the deny:

    /0010 { /type "allow" /method "POST" /url "/bin/customservlet" }

    Remember on AEMaaCS, dispatcher config is deployed via Cloud Manager pipeline, not manually. A config that works on author (which bypasses dispatcher) will fail on publish.

     

    2. CDN-level traffic filtering
    Your cdn.log shows `cache:PASS` which means the CDN did forward the request, so CDN caching rules are not blocking it. However, check if you have any custom CDN rules (via Adobe-managed CDN config in your Cloud Manager environment) that might redirect or block POST requests.

     

    3. Sling Servlet Registration on Publish
    If dispatcher is confirmed open, verify the servlet is actually registered on publish. Go to:
    https://publish-p170552-e1826604.adobeaemcloud.com/system/console/servletresolver

    Note: this console is only accessible on author directly. For publish, check via the AEM Cloud Service Developer Console in Cloud Manager go to your environment, Publish pod, and check the OSGi servlet registry to confirm your servlet bundle is active.

     

    4. Replication of supporting content/config
    If your servlet depends on any OSGi config or content paths, confirm those have been replicated/deployed to publish as well.

     

    Most likely culprit: dispatcher filter. Start there first.

    avesh_narang
    avesh_narang
    Level 4
    May 15, 2026

    Adding to ​@akhil_merupula  above reply , ​@helloosuman if you will be able to validate the redirect location from 301 response ,you’ll pinpoint exactly which layer is enforcing it.

    Thanks !

      H
      helloosumanAuthor
      Level 2
      May 15, 2026

      ​@akhil_merupula  ​@avesh_narang  thank you so much for your prompt response. I forgot to mention that I already have following filter.any entry in dispatcher:

      /0123 { /type "allow" /method "POST" /url "/bin/jiraapi/createTicket" }

      I’m checking other details which Akhil mentioned.

      lavishvasuja
      lavishvasuja
      Level 4
      May 16, 2026

      Since the request is visible in CDN logs but not in Publish access.log, request.log, or error.log, it looks like the request is not reaching the Publish instance and is likely being handled at the CDN/Dispatcher layer.

      Also, the CDN log shows a 301 response for the POST request on /bin/customservlet, which suggests a redirect rather than a servlet execution issue. It would be worth checking whether:

      the request is initially hitting HTTP and then getting redirected to HTTPS, or
      any rewrite/canonical redirect is configured for this endpoint.

      Regarding Dispatcher filters, I currently see an allow rule for:

      /type "allow"
      /method "POST"
      /url "/bin/jiraapi/createTicket"

      Could you please confirm whether the failing request is targeting this same endpoint or a different servlet path such as /bin/customservlet?

      It would also help to inspect the response headers (especially the Location header) from the browser Network tab or Postman/cURL output to identify where the 301 is redirecting.

      H
      helloosumanAuthor
      Level 2
      May 19, 2026

      Please note the same servlet works fine in AMS author/ publish environment. We are migrating to aemaacs. Servlet works fine in aemaacs author environment . I’ve now made following changes in filter.any file

      ******

      /0117 { /type "deny" /method "GET" /path "/bin/*" }

      /0118 { /type "allow" /method "POST" /url "/bin/jiraapi/createTicket" }

      ******

      it's still failing with following error:

      *********

      log file name : dispatcher_httpdaccess_2026-05-19.log

      cm-p170552-e2062200-aem-publish-68b66bd45c-s4cvb 192.223.233.179 - 19/May/2026:00:08:31 +0000 "POST /bin/jiraapi/createTicket HTTP/1.1" 301 299 "https://<publishurl>/content/mygps-feedback.html?locationURL=https://<publishurl>/content/mygps/us/en/pi/public/tax/federal-and-state-taxes/529-able-and-custodial-accounts/3ac8369e-7ae2-40a4-9779-14a6b010cb22_ditamap/Referenceaba7e256-8159-4782-a00c-b58b9502cc07.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36"

      ******

      Created adobe support ticket(got ultimate support ) but, even, adobe support is too struggling to resolve.

      A
      akhil_merupula
      Level 4
      May 19, 2026

      ​Thanks for the update ​@helloosuman. The 301 is actually the key detail here and it changes the diagnosis completely. The dispatcher filter is not the issue since you already have the allow rule in place. A 301 means the request is being redirected somewhere else before it can reach your servlet.

       

      The most likely cause is an HTTP to HTTPS redirect. If your POST request is being made over HTTP, AEMaaCS will redirect it to HTTPS with a 301, and most clients do not follow POST redirects correctly, they either convert to GET or drop the request entirely. Check the Location header in the 301 response to see exactly where it is redirecting. You can do this by running curl -v -X POST your-endpoint-url and looking at the Location header in the response.

       

      Second possibility is a trailing slash redirect. If your servlet path is /bin/jiraapi/createTicket and the request is being sent as /bin/jiraapi/createTicket/ with a trailing slash or vice versa, the server will 301 to the correct path. Again the Location header will confirm this.

       

      Third check your Apache/httpd config in your dispatcher module for any rewrite rules that might be catching POST requests to /bin/ paths and redirecting them. Even with the filter.any allowing the request, an Apache RewriteRule can intercept it before the filter logic applies.

       

      Can you share what the Location header shows in the 301 response? That will tell us exactly where the redirect is pointing and confirm which of these is the cause.
       

      H
      helloosumanAuthor
      Level 2
      May 19, 2026

      ​@akhil_merupula Here is the complete response: (I’ve removed few lines with publish url and certificate & cookie details)

      < HTTP/1.1 200 Connection Established
      < Proxy-Agent: Zscaler/6.2
      < 
      * CONNECT phase completed
      * CONNECT tunnel established, response 200
      * ALPN: curl offers h2,http/1.1
      * (304) (OUT), TLS handshake, Client hello (1):
      *  CAfile: /opt/homebrew/etc/ca-certificates/cert.pem
      *  CApath: none
      * (304) (IN), TLS handshake, Server hello (2):
      * (304) (IN), TLS handshake, Unknown (8):
      * (304) (IN), TLS handshake, Certificate (11):
      * (304) (IN), TLS handshake, CERT verify (15):
      * (304) (IN), TLS handshake, Finished (20):
      * (304) (OUT), TLS handshake, Finished (20):
      * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
      * ALPN: server accepted h2
      * Server certificate:
      *  subject: C=US; ST=California; L=San Jose; O=Adobe Inc.; CN=*.adobeaemcloud.com
      *  start date: Sep 11 00:00:00 2025 GMT
      *  expire date: Oct 12 23:59:59 2026 GMT
      *  subjectAltName: host "<publishurl>" matched cert's "*.adobeaemcloud.com"
      *  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
      *  SSL certificate verify ok.
      * using HTTP/2
      * [HTTP/2] [1] OPENED stream for https://<publishurl>/bin/jiraapi/createTicket
      * [HTTP/2] [1] [:method: POST]
      * [HTTP/2] [1] [:scheme: https]
      * [HTTP/2] [1] [:authority: <publishurl>]
      * [HTTP/2] [1] [:path: /bin/jiraapi/createTicket]
      * [HTTP/2] [1] [accept: */*]
      * [HTTP/2] [1] [accept-language: en-US,en;q=0.9]
      * [HTTP/2] [1] [content-type: application/x-www-form-urlencoded; charset=UTF-8]
      * [HTTP/2] [1] [origin: https://<publishurl>]
      * [HTTP/2] [1] [referer: https://<publishurl>/content/mygps-feedback.html?locationURL=https://<publishurl>/content/mygps/us/en/pi/public/tax/federal-and-state-taxes/529-able-and-custodial-accounts/3ac8369e-7ae2-40a4-9779-14a6b010cb22_ditamap/Referenceaba7e256-8159-4782-a00c-b58b9502cc07.html]
      * [HTTP/2] [1] [sec-fetch-dest: empty]
      * [HTTP/2] [1] [sec-fetch-mode: cors]
      * [HTTP/2] [1] [sec-fetch-site: same-origin]
      * [HTTP/2] [1] [user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36]
      * [HTTP/2] [1] [x-requested-with: XMLHttpRequest]
      * [HTTP/2] [1] [sec-ch-ua: "Chromium";v="148", "Google Chrome";v="148", "Not/A)Brand";v="99"]
      * [HTTP/2] [1] [sec-ch-ua-mobile: ?0]
      * [HTTP/2] [1] [sec-ch-ua-platform: "macOS"]
      * [HTTP/2] [1] [content-length: 751]
      > POST /bin/jiraapi/createTicket HTTP/2
      > Host: <publishurl>
      > Accept: */*
      > Accept-Language: en-US,en;q=0.9
      > Connection: keep-alive
      > Content-Type: application/x-www-form-urlencoded; charset=UTF-8
      > Origin: https://<publishurl>
      > Referer: https://<publishurl>/content/mygps-feedback.html?locationURL=https://<publishurl>/content/mygps/us/en/pi/public/tax/federal-and-state-taxes/529-able-and-custodial-accounts/3ac8369e-7ae2-40a4-9779-14a6b010cb22_ditamap/Referenceaba7e256-8159-4782-a00c-b58b9502cc07.html
      > Sec-Fetch-Dest: empty
      > Sec-Fetch-Mode: cors
      > Sec-Fetch-Site: same-origin
      > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36
      > X-Requested-With: XMLHttpRequest
      > sec-ch-ua: "Chromium";v="148", "Google Chrome";v="148", "Not/A)Brand";v="99"
      > sec-ch-ua-mobile: ?0
      > sec-ch-ua-platform: "macOS"
      > Content-Length: 751
      > 
      * upload completely sent off: 751 bytes
      < HTTP/2 301 
      < location: https://${MYGPS_HOST}/bin/jiraapi/createTicket.html
      < cache-control: max-age=300
      < expires: Tue, 19 May 2026 05:05:39 GMT
      < content-type: text/html; charset=iso-8859-1
      < accept-ranges: bytes
      < date: Tue, 19 May 2026 05:00:39 GMT
      < strict-transport-security: max-age=31557600
      < x-served-by: cache-dfw-kdal2120056-DFW
      < x-cache: MISS
      < x-timer: S1779166839.136153,VS0,VS0,VE220
      < content-length: 299
      < 
      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
      <html><head>
      <title>301 Moved Permanently</title>
      </head><body>
      <h1>Moved Permanently</h1>
      <p>The document has moved <a href="https://${MYGPS_HOST}/bin/jiraapi/createTicket.html">here</a>.</p>
      </body></html>

      H
      helloosumanAuthorAccepted solution
      Level 2
      May 19, 2026

      ​@akhil_merupula ​@avesh_narang  it started working with following changes:

      RewriteCond %{REQUEST_URI} !^/bin/jiraapi/createTicket     RewriteRule ^([^.]*[^./])$ https://${MYGPS_HOST}$1.html [R=301,L]

      Order of above is very important though.

        A
        akhil_merupula
        Level 4
        May 19, 2026

        ​@helloosuman 

        Great news! yes the order is critical, the RewriteCond exception must appear immediately before the RewriteRule it applies to, otherwise Apache evaluates them independently and the condition has no effect on the rule.

         

        Good call noting that for anyone else who hits this, the fix is straightforward but the rule ordering trips people up more than the fix itself.
         

          Terms & ConditionsAccessibility statement

          Loading footer...