Solr
  1. Solr
  2. SOLR-2022

request handler paths ending in "/" don't work with Tomcat 7

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.1.0, 1.2, 1.3, 1.4, 1.4.1, 1.4.2, 1.5, 3.1, 3.2, 4.0-ALPHA
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      As originally reported in this thread...

      http://search.lucidimagination.com/search/document/9c09498631b7afbb/problems_running_on_tomcat

      Tomcat 7 has made changes in how URLs are resolved that result in the requests with paths that end in a "/" character being given to the SolrDispatchFilter with "index.jsp" appended to them. This results in SolrDispatchFilter being unable to correctly identify some situations when a request should be processed by a request handler based on the name registered (ie: "/update/csv/" is seen as "update/csv/index.jsp" so as a result the handler registered to "/update/csv/ is not consulted). The problem manifests as a generic 404 (because the request is propagated to the underlying JspServlet which can not find these paths and jsps in the war)

      This is most notable in a basic solr install when clicking some URLs that are linked to from the main admin page (see comments below) but this problem can also affect any situation where a client is attempting to access a request handler (or "/select/") using a path ending in "/". The workaround is to remove hte trailing "/" character

        Issue Links

          Activity

          Hoss Man created issue -
          Hide
          Hoss Man added a comment -

          Verified the symptoms described using Solr 1.4.1 and tomcat 7.0.4

          Specific problems...

          From admin screen, running solr in a webapp named "demo" with a a core named "books" and loading the admin screen...

          http://localhost:8080/demo/books/admin/

          the "schema.xml" and "config" links point to these URLs...

          http://localhost:8080/demo/books/admin/file/?file=schema.xml
          http://localhost:8080/demo/books/admin/file/?file=solrconfig.xml
          

          ...those both generate 404 error messages with this descriptions...

          message /demo/admin/file/index.jsp
          description The requested resource (/demo/admin/file/index.jsp) is not available.
          

          ...manullly changing the urls to remove the "/" prior to the question mark makes the URLs work fine.

          Clicking the "Search" button on the main admin screen leads to...

          http://localhost:8080/demo/books/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on
          

          ..which also fails. again removing the "/" prior to the question mark makes it work.

          Show
          Hoss Man added a comment - Verified the symptoms described using Solr 1.4.1 and tomcat 7.0.4 Specific problems... From admin screen, running solr in a webapp named "demo" with a a core named "books" and loading the admin screen... http://localhost:8080/demo/books/admin/ the "schema.xml" and "config" links point to these URLs... http://localhost:8080/demo/books/admin/file/?file=schema.xml http://localhost:8080/demo/books/admin/file/?file=solrconfig.xml ...those both generate 404 error messages with this descriptions... message /demo/admin/file/index.jsp description The requested resource (/demo/admin/file/index.jsp) is not available. ...manullly changing the urls to remove the "/" prior to the question mark makes the URLs work fine. Clicking the "Search" button on the main admin screen leads to... http://localhost:8080/demo/books/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on ..which also fails. again removing the "/" prior to the question mark makes it work.
          Hide
          Hoss Man added a comment -

          Well, the root cause seems to be a bug in tomcat...

          https://issues.apache.org/bugzilla/show_bug.cgi?id=50161

          for these specific links, we could work around the problem by removing the trailing "/" in any links on the admin screen to a solr handler (SolrCore internally normalizes handler paths and ignores the trailing "/" anyway) but that wouldn't help any users who have clients hitting ".../select/?..." (or any other handler) that try to upgrade tomcat.

          Show
          Hoss Man added a comment - Well, the root cause seems to be a bug in tomcat... https://issues.apache.org/bugzilla/show_bug.cgi?id=50161 for these specific links, we could work around the problem by removing the trailing "/" in any links on the admin screen to a solr handler (SolrCore internally normalizes handler paths and ignores the trailing "/" anyway) but that wouldn't help any users who have clients hitting ".../select/?..." (or any other handler) that try to upgrade tomcat.
          Hide
          Hoss Man added a comment -

          updated summary and description now that root cause has been identified

          Show
          Hoss Man added a comment - updated summary and description now that root cause has been identified
          Hoss Man made changes -
          Field Original Value New Value
          Summary Annecdotal evidence that Solr has problems running on Tomcat 7 request handler paths ending in "/" don't work with Tomcat 7
          Affects Version/s 1.4 [ 12313351 ]
          Affects Version/s 1.3 [ 12312486 ]
          Affects Version/s 1.2 [ 12312235 ]
          Affects Version/s 1.1.0 [ 12312234 ]
          Affects Version/s 1.4.2 [ 12315231 ]
          Affects Version/s 1.5 [ 12313566 ]
          Affects Version/s 3.1 [ 12314371 ]
          Affects Version/s 4.0 [ 12314992 ]
          Affects Version/s Next [ 12315093 ]
          Description Based on this thread, users seem to have problems with Solr on tomcat 7 that do not exist on tomcat 6...

          http://search.lucidimagination.com/search/document/9c09498631b7afbb/problems_running_on_tomcat

          based on the descri[ption of hte problem, it seems to be related to the way links of the admin screen work (possibly due to changes in how tomcat prioritizes SolrDispatchFilter vs other JSP based links?)
          Based on this thread, users seem to have problems with Solr on tomcat 7 that do not exist on tomcat 6...

          http://search.lucidimagination.com/search/document/9c09498631b7afbb/problems_running_on_tomcat
          Hide
          Hoss Man added a comment -

          FYI: comments in tomcat bug#50161 that this is a result of a deliberate change in order to correctly implement Servlet Spec 3.0 - but i've posted some followup questions - in particular, it's not clear to me that HttpServletRequest.getServletPath() is returning what it should be even in light of the comments posted.

          There is some mention that future versions of tomcat may allow a system property to override this behavior from the servlet spec, but in future versions of Solr we should probably don't want to have to rely on that being set. There may be ways we can work around this behavior a little better – depending on what response we get in bug#50161 we might consider changes to our web.xml to override the default "welcome-file" behavior, or changing the way SolrDispatchFilter attempts to parse the URL path.

          Show
          Hoss Man added a comment - FYI: comments in tomcat bug#50161 that this is a result of a deliberate change in order to correctly implement Servlet Spec 3.0 - but i've posted some followup questions - in particular, it's not clear to me that HttpServletRequest.getServletPath() is returning what it should be even in light of the comments posted. There is some mention that future versions of tomcat may allow a system property to override this behavior from the servlet spec, but in future versions of Solr we should probably don't want to have to rely on that being set. There may be ways we can work around this behavior a little better – depending on what response we get in bug#50161 we might consider changes to our web.xml to override the default "welcome-file" behavior, or changing the way SolrDispatchFilter attempts to parse the URL path.
          Hide
          Hoss Man added a comment -

          Updated description to clarify the scope of hte problem

          Show
          Hoss Man added a comment - Updated description to clarify the scope of hte problem
          Hoss Man made changes -
          Description Based on this thread, users seem to have problems with Solr on tomcat 7 that do not exist on tomcat 6...

          http://search.lucidimagination.com/search/document/9c09498631b7afbb/problems_running_on_tomcat
          As originally reported in this thread...

          http://search.lucidimagination.com/search/document/9c09498631b7afbb/problems_running_on_tomcat

          Tomcat 7 has made changes in how URLs are resolved that result in the requests with paths that end in a "/" character being given to the SolrDispatchFilter with "index.jsp" appended to them. This results in SolrDispatchFilter being unable to correctly identify some situations when a request should be processed by a request handler based on the name registered (ie: "/update/csv/" is seen as "update/csv/index.jsp" so as a result the handler registered to "/update/csv/ is not consulted). The problem manifests as a generic 404 (because the request is propagated to the underlying JspServlet which can not find these paths and jsps in the war)

          This is most notable in a basic solr install when clicking some URLs that are linked to from the main admin page (see comments below) but this problem can also affect any situation where a client is attempting to access a request handler (or "/select/") using a path ending in "/". The workaround is to remove hte trailing "/" character
          Hoss Man made changes -
          Link This issue is duplicated by SOLR-2262 [ SOLR-2262 ]
          Hoss Man made changes -
          Affects Version/s 3.2 [ 12316172 ]
          Affects Version/s Next [ 12315093 ]
          Hide
          Jan Høydahl added a comment -

          Tomcat admitted this was their bug and since Tomcat 7.0.5 this is fixed. See https://issues.apache.org/bugzilla/show_bug.cgi?id=49422#c8

          Resolving as "Won't fix", since solution is to upgrade Tomcat

          Show
          Jan Høydahl added a comment - Tomcat admitted this was their bug and since Tomcat 7.0.5 this is fixed. See https://issues.apache.org/bugzilla/show_bug.cgi?id=49422#c8 Resolving as "Won't fix", since solution is to upgrade Tomcat
          Jan Høydahl made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Won't Fix [ 2 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Hoss Man
            • Votes:
              3 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development