Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Constantly receiving a Http404 when using IIS with dispatcher.

Avatar

Former Community Member

Hi

We are having problems getting any thing back from CQ when using a dispatcher & IIS7. The intention is to route requests from the route website on IIS to the CQ publishing instance. 

We have followed all the instructions on these pages:

We were initially recieving nothing but http500 errors but after correcting the basic setup described in the second page we now get nothing but http404.

We have created a dispatcher.any which is definitely being read as changing it affects the behaviour of CQ.

This file is as follows:

# name of the dispatcher
/name "dev-server"
 
/farms
  {
    # first farm entry (label is not important, just for your convenience)
    /website 
    { 
    /homepage "/"
    
    /clientheaders
        {
        # List of headers that are passed on
        "*"
        }
        
    # List of URLs for this Web site
    # The following configuration causes Dispatcher to handle all requests:
    /virtualhosts
      {
      "*"
      }
    
    # The "/renders" property defines the URL to which Dispatcher sends requests to render a document. 
    /renders
      {
      # List of AEM instances that render the documents
      /publishRenderer
        {
        # hostname or IP of the renderer
        /hostname "127.0.0.1"
        # port of the renderer
        /port "4503"
        # connection timeout in milliseconds, "0" (default) waits indefinitely
        /timeout "0"
        }
      }
    /filter
      {
      # List of filters
      /0001
        {
        # If you want the Dispatcher to handle all files
        /glob "*"
        /type "allow"
        }
      }
    /cache
        {
        # Cache configuration
        /docroot "C:\\inetpub\\cache\\farms\\website"
        }
    }
  }

We have the following error appearing in our logs.

 

[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Dispatcher initializing (build 4.1.5)
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] farms[website].homepage = /
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] farms[website].cache.docroot = C:\inetpub\cache\farms\website
[Wed Nov 27 17:05:27 2013] [I] [4616(2676)] Dispatcher initialized (build 4.1.5)
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Found farm website for localhost
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] checking []
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] no cache due to missing extenson in uri: 
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] cache-action for []: NONE
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] connected to backend publishRenderer (127.0.0.1:4503)
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: cookie
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: host
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: accept-language
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: user-agent
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: dnt
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: accept
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Spooling request header: accept-encoding
[Wed Nov 27 17:05:27 2013] [D] [4616(2676)] Content length: -1, written: 101
[Wed Nov 27 17:05:27 2013] [I] [4616(2676)] "GET " 404 ~ 0ms

At this time we have no clue what to do and have been experimenting with this for over a day.

Please advise.

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

Hi,

We eventually resolved this issue.
The clue  was in the log line:

[Thu Nov 28 10:37:13 2013] [D] [5496(5604)] checking []

Every other forum or Knowledge base post had something like the following in it:

[Thu Nov 28 11:13:34 2013] [D] [5824(4488)] checking [/content/geometrixx-outdoors/en/seasonal/summer/_jcr_content/par/banner.img.jpg/1354278209455.jpg]

So we went looking at the IIS configuration.

The advise on configuring the ISAPI module is to add a "Handler Mapping" with a path of "*".
The issue seems to be that unless you remove all other handlers that are mapped to "*" ... which will be installed by default by IIS ... then the URI of your requested page is not passed to the dispatcher.

The dispatcher gets no URI so AEM does not know what to do hence a http404.

Problem solved.

View solution in original post

4 Replies

Avatar

Level 10

Try this KB article: http://helpx.adobe.com/experience-manager/kb/SSOwithApacheIIS.html.

If that does not help you - along with the product documentation, then there is a bug. Please file a ticket at: http://helpx.adobe.com/marketing-cloud/experience-manager.html.

Avatar

Former Community Member

I am unsure why you think authentication is the root cause of the issue?

We are using a publisher instance and the problem occurs when requesting the first page from the site.
Any user would have not authenticated at this point. 

Please advise.

Avatar

Former Community Member

There is a post on the knowledge base (http://helpx.adobe.com/experience-manager/kb/IIS6IsapiFilters.html) but it quotes an image that is no longer accessible.

Help?

Avatar

Correct answer by
Former Community Member

Hi,

We eventually resolved this issue.
The clue  was in the log line:

[Thu Nov 28 10:37:13 2013] [D] [5496(5604)] checking []

Every other forum or Knowledge base post had something like the following in it:

[Thu Nov 28 11:13:34 2013] [D] [5824(4488)] checking [/content/geometrixx-outdoors/en/seasonal/summer/_jcr_content/par/banner.img.jpg/1354278209455.jpg]

So we went looking at the IIS configuration.

The advise on configuring the ISAPI module is to add a "Handler Mapping" with a path of "*".
The issue seems to be that unless you remove all other handlers that are mapped to "*" ... which will be installed by default by IIS ... then the URI of your requested page is not passed to the dispatcher.

The dispatcher gets no URI so AEM does not know what to do hence a http404.

Problem solved.

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----