In response to the inevitable question "why not just move all /solr/* URLs to /, i re-iterate my comment to this topic on the mailing list last month...

PS: Same goes for the default URL. We could move to toplevel now http://localhost:8983/

-0 ... i don't see any downside to leaving "/solr/" in the URL, and if/when we rip out the jetty stack completley and stop beholding to the servlet APIs internally it gives us flexibility if we want to start deprecating/retring things to be able to say "All of the legacy, pre-Solr X.0, APIs use a base path of '/solr/' and all the new hotness APIs use a base path of '/v2/'" ... or something like that.

patch leveraging a bit of jetty magic to do this.

Hmm, not sure i'm a fan of this solution actually...

it only only redirects "/" it also redirects "/anything_other_then_solr"...

http://localhost:8983/garbage -> http://localhost:8983/solr/

...this seems like a bad idea. My goal was simply to make "http://localhost:8983/" send you someplace useful, but if people are making up giberish URLs – or have typos in client connection urls (eg: "http://localhost:8983/Solr/MyCollection/select") those should really just return 404 rather then silently rewriting to ".../solr/"

Re: your comment on having /solr so that we could have an incompatible /v2 in the future: wouldn't the same concern apply to the redirect as well? I.e. what API is the root url going to service during such an API shift? It leads to the root URL being on the oldest version if it stays on v1, but if always redirect it to v2, we are waiving off all backward compatibility requirements for the root url alone – how do we communicate this discrepancy in compatibility guarantees between the two URLs? And how useful is it going to be if we say that the meaning of the redirect is going to change under your feet without notice?

... what API is the root url going to service during such an API shift?

Your concern is precisely the reason i said i do not like the patch i put up. When i threw it together, i did not intend/expect that it would cause /foo to redict to /solr ... i missunderstood what Jetty's MovedContextHandlerthe does.

I do not want people to mistakenly rely on any sort of redirecting to server the "current" API ... i was solely trying to put in place a redirect for the singular url of "/" so that the user experience on loading "/" in a browser would be slightly less ugly.

I agree that redirecting /whatever would be a bad idea. +1 to redirecting ONLY the specific "/" url to the admin UI on /solr, or whatever it might be in the future.

GitHub user makuk66 opened a pull request:

https://github.com/apache/lucene-solr/pull/136

SOLR-7240 add redirect of / to /solr/

SOLR-7240 add redirect of / to /solr/, using the jetty rewrite module with a regex pattern

With this patch, / (and only /) redirects to /solr/.

Tested with `bin/solr -f` on OSX:

```
$ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 8983
HTTP/1.1 302 Found
Location: http://127.0.0.1:8983/solr/
Content-Length: 0

$ printf "GET /solr/ HTTP/1.0\r\n\r\n" | nc localhost 8983 | grep '<title>'
<title>Solr Admin</title>
$ printf "GET /foo HTTP/1.0\r\n\r\n" | nc localhost 8983 | grep '<title>'
<title>Error 404 Not Found</title>
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/makuk66/lucene-solr SOLR-7240-redirect-slash-to-solr-squashed

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/136.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #136

commit 7bab2d8ab38a8e27fe606e63eb7ae6f48181a492
Author: Martijn Koster <mak-github@greenhills.co.uk>
Date: 2015-03-25T08:18:28Z

SOLR-7240 add redirect of / to /solr/, using the jetty rewrite module with a regex pattern

Mak's patch is against 5x and looks appropriate for jetty8 – but on trunk, with jetty9, i know that "OPTIONS=..." syntax is no longer supported.

inspired by mak's patch, i created this one for trunk. I thought we'd need to modifiy solr/server/start.ini, to include "rewrite" in the --module list, but when i tried that out i got an error in the logs that "rewrite" wasn't a valid module name, and regardless of that change hte rewrite worked – so i guess this handler is part of the core in jetty9? not sure.

I'm running precommit now, i'll get this into trunk later today and then test mak's patch more thoroughly on the 5x branch.

Commit 1669431 from hossman@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1669431 ]

SOLR-7240: '/' redirects to '/solr/' for convinience

Commit 1669433 from hossman@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1669433 ]

SOLR-7240 CHANGES typo

Commit 1669448 from hossman@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1669448 ]

SOLR-7240 Another CHANGES typo .. sure ... why not.

Commit 1669452 from hossman@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1669452 ]

SOLR-7240: '/' redirects to '/solr/' for convenience (merge 1669431, 1669433, 1669448, This closes #136)

Solr won't start if using: java -jar start.jar

[~/dev/lw/projects/br5x/solr/server]$ java -jar start.jar
0    [main] WARN  org.eclipse.jetty.xml.XmlConfiguration  [] [] [] [] – Config error at <New id="RewriteHandler" class="org.eclipse.jetty.rewrite.handler.RewriteHandler"><Set name="rewriteRequestURI">true</Set><Set name="rewritePathInfo">false</Set><Set name="originalPathAttribute">requestedPath</Set><Call name="addRule"><Arg>
         <New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule"><Set name="regex">^/$</Set><Set name="replacement">/solr/</Set></New>
       </Arg></Call></New>
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.eclipse.jetty.start.Main.invokeMain(Main.java:473)
    at org.eclipse.jetty.start.Main.start(Main.java:615)
    at org.eclipse.jetty.start.Main.main(Main.java:96)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.rewrite.handler.RewriteHandler
    at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at org.eclipse.jetty.util.Loader.loadClass(Loader.java:100)
    at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.nodeClass(XmlConfiguration.java:354)
    at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:754)
    at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:392)
    at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:343)
    at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:296)
    at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1247)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1182)
    ... 7 more

Usage: java -jar start.jar [options] [properties] [configs]
      java -jar start.jar --help  # for more information

Of course, you should use bin/solr to start Solr, but I don't think we ever declared using java -jar start.jar is no longer supported?

Marking this as a blocker for 5.1. Although bin/solr is the preferred method of starting Solr, using java -jar start.jar should still work.

Mak has proposed a solution for this: https://gist.github.com/makuk66/20c736ae47fc4993c461

However, here's Chris Hostetter (Unused) take on this:
"As of solr5 we very clearly document that the only supported way to run solr is bin/solr - we may not have ever explicitly said start.jar was no longer supported, but we shouldn't have ever needed to because it was never officially supported either - it was just an example of how to run solr in jetty.

If we're going to hold back on stuff like this now, I don't see how were ever going to leave ourselves enough room to gradually replace the internals like we've talked about for a while, unless we commit to rolling our own start.jar

I won't stand in the way if people think this is important, but I give up on trying to move past "solr is just a web app" if we worry about stuff like this."

Scripts in solr/cloud-dev/ rely on start.jar... (and are broken right now)

Ok, thanks Gus Heck ... problem is bigger than I realized

Here's a patch that fixes this issue for branch5x.

Still looking into how to fix for trunk b/c it runs on Jetty 9

hmm, you seem to have managed to link my old account (from when I worked at Olin College)... wonder how I can keep people from doing that, I have no access to it anymore.

I am with Hoss on this one. But given that we have a patch for branch_5x, could we leave trunk broken and remove support for 5.2?

Thanks for chiming in Ramkumar Aiyengar ... I think trunk has been broken for a while because java -jar start.jar starts up Jetty 9, but doesn't deploy the WAR. I'm going to commit my fix for 5.1 to unblock that release and open a new JIRA to remove support for it in a later release.

Commit 1670788 from Timothy Potter in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1670788 ]

SOLR-7240: add start.ini in the server directory so java -jar start.jar continues to work on Jetty 8

Commit 1670793 from Timothy Potter in branch 'dev/branches/lucene_solr_5_1'
[ https://svn.apache.org/r1670793 ]

SOLR-7240: add start.ini in the server directory so java -jar start.jar continues to work on Jetty 8

java -jar start.jar works on 5.1 branch now ... but it will soon be an unsupported way to start solr after 5.1

Bulk close after 5.1 release

hmm, I'm noticing that the "trunk" patch for this (and 5.3.1 release files) contains these lines:

            <Item>
+             <Ref id="RewriteHandler"/>
+           </Item>

Is this part of the config working as expected? The documentation for Jetty seems to say that this shoud be

            <Item>
+             <Ref refid="RewriteHandler"/>
+           </Item>

If it's all working as expected then I guess the fact that Intellij flags an error here (duplicate id attributes) is not a big deal. However, if something is awry here maybe we need to open a new ticket to deal with it (since this one is already closed). I haven't (yet) run into a symptom, but this looks funny...

I assume both will work for compatibility reasons. But IntelliJ is right, you cannot have duplicate id values. Same we know from ant: <javac classpathref="..."/> pointing to <classpath id="..."/>.