Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: search
    • Labels:
      None

      Description

      Instead of 'qt' being handled by the SolrDispatchFilter (a Servlet Filter), it would be better implemented as a request handler, with a suggested name of DispatchingRequestHandler. This is better because:

      • it keeps the servlet filter more focused / simplified (albeit just a little)
      • it simplifies solrconfig.xml by removing/deprecating handleSelect="true". 'qt' is less magic, it works more explicitly.
      • if you don't want to use 'qt' dispatch, simply don't use DispatchingRequestHandler
      • DispatchingRequestHandler would get used by EmbeddedSolrServer but SolrDispatchFilter is not.

      Credit: Hoss's idea, Erik coded a first draft

        Issue Links

          Activity

          Hide
          Yonik Seeley added a comment -

          I think I would prefer leaving things as they are (as you say, it's just a small piece of code in the SolrDispatchFilter... and "qt" is all about dispatching!)
          It would seem to introduce extra overhead for anyone that wanted to use "qt" as they did before, and there's a good probability that it would introduce more bugs as well.

          Show
          Yonik Seeley added a comment - I think I would prefer leaving things as they are (as you say, it's just a small piece of code in the SolrDispatchFilter... and "qt" is all about dispatching!) It would seem to introduce extra overhead for anyone that wanted to use "qt" as they did before, and there's a good probability that it would introduce more bugs as well.
          Hide
          Hoss Man added a comment -

          Credit: Hoss's idea

          to be clear, i did not suggest that we should eliminate qt support from SolrDispatchFilter.

          what i said in SOLR-3161 was...

          change the example solrocnfig to use handleSelect="false"
          ...
          Bonus points: someone can write a DispatchingRequestHandler that can optionally be configured with some name (such as "/select") and does nothing put look for a "qt" param and forward to the handler with that name – but it can have configuration options indicating which names are permitted (and any other names would be rejected)

          my entire point was that we should leave in support for 'handleSelect="true"' exactly as it is for the multitudes of existing users who are happy using "qt" w/o any security concerns, but that we could also offer an optional DispatchingRequestHandler for people who want param based dispatching but want to limit it to only certain handlers

          Show
          Hoss Man added a comment - Credit: Hoss's idea to be clear, i did not suggest that we should eliminate qt support from SolrDispatchFilter. what i said in SOLR-3161 was... change the example solrocnfig to use handleSelect="false" ... Bonus points: someone can write a DispatchingRequestHandler that can optionally be configured with some name (such as "/select") and does nothing put look for a "qt" param and forward to the handler with that name – but it can have configuration options indicating which names are permitted (and any other names would be rejected) my entire point was that we should leave in support for 'handleSelect="true"' exactly as it is for the multitudes of existing users who are happy using "qt" w/o any security concerns, but that we could also offer an optional DispatchingRequestHandler for people who want param based dispatching but want to limit it to only certain handlers
          Hide
          Erik Hatcher added a comment -

          I'm too overwhelmed with other stuff to battle this, but I entirely disagree. SolrDispatchFilter needs to have it's logic moved down a layer when it comes to determining which request handler to hit, in my opinion. Having this kind of logic at the web tier, for one thing, requires that folks using Solr embedded (or in direct connection kinda tests) have to recreate this logic. That's just one reason we should eliminate the handleSelect/qt business. As we've seen, though, it's a thorny topic that necessitates changes in 3rd party clients, etc to eliminate qt, and this is what this issue is about - keeping a backwards-compatible layer for qt support while making it trivial to enable or not. Hoss mentioned "multitudes of existing users who are happy using 'qt' without security concerns" - my assertion is that these users don't know the types of capabilities that are open (perhaps thinking if they just removed/blocked /admin that they'd be safer).

          Show
          Erik Hatcher added a comment - I'm too overwhelmed with other stuff to battle this, but I entirely disagree. SolrDispatchFilter needs to have it's logic moved down a layer when it comes to determining which request handler to hit, in my opinion. Having this kind of logic at the web tier, for one thing, requires that folks using Solr embedded (or in direct connection kinda tests) have to recreate this logic. That's just one reason we should eliminate the handleSelect/qt business. As we've seen, though, it's a thorny topic that necessitates changes in 3rd party clients, etc to eliminate qt, and this is what this issue is about - keeping a backwards-compatible layer for qt support while making it trivial to enable or not. Hoss mentioned "multitudes of existing users who are happy using 'qt' without security concerns" - my assertion is that these users don't know the types of capabilities that are open (perhaps thinking if they just removed/blocked /admin that they'd be safer).
          Hide
          Steve Rowe added a comment -

          Bulk move 4.4 issues to 4.5 and 5.0

          Show
          Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0

            People

            • Assignee:
              Unassigned
              Reporter:
              David Smiley
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development