: To be clear, (with the current implementation in SOLR-104) you would : have to put this in your solrconfig.xml : : <requestHandler name="/select" class="solr.StandardRequestHandler"> : : Notice the preceding '/'. I think this is a strong indication that : someone *wants* /select to behave distinctly.
crap ... i totally misread that ... so if people have a requestHandler registered with a name that doesn't start with a slash, they can't use the new URL structure and they have to use the old one. DAMN! ... that is slick dude ... okay, i agree with you, the odds of that causing problems are pretty fucking low. I'm still hung up on this "parse" logic thing ... i really think it needs to be in the path .. or at the very least, there needs to be a way to specify it in the path to force one behavior or another, and if it's not in the path then we can guess based on the Content-Type. Putting it in a query arg would make getting it without contaminating the POST body kludgy, putting it at the start of the path doesn't work well for supporting a default if it isn't there, and putting it at the end of the PATH messes up the nice work you've done letting RequestHandlers have extra path info for encoding info they want. Hmmmm... What if we did soemthing like this... /exec/handler/name:extra/path?param1=val1 /raw/handler/name:extra/path?param1=val1 /url/handler/name:extra/path?param1=val1&url=...&url=... /file/handler/name:extra/path?param1=val1&file=...&file=... where "exec" means guess based on the Content-TYpe, "raw" means use the POST body as a single stream regardless of Content-Type, etc... thoughts? -Hoss
