> A crawler ... could do very bad things if [unleashed on] a wiki with > instructions on how to maintain their deployed solr,
What a terrifyingly imaginative example haha! Thanks all for the pointers and ideas! Gus - I definitely see the value in making better use of the servlet/filter abstractions to organize v1/v2 code. I'm not sure the "endpoint reshaping" work I'm setting out to do will take me close to that code at all, but I'll keep it in mind in case I find overlap we can take advantage of. It sounds like there's general consensus around improving the v2 API surface. To summarize some of the points discussed: 1. We are interested in improving v2. 2. REST (including more meaningful use of HTTP verbs and delineation of "read" vs "write" APIs) and OpenAPI compatibility as organizing principles. 3. Changes can largely be made "in place" without needing a whole new "v3" or strict concern for backcompat. (Though in some places preserving backcompat will make sense or even be required to support rolling upgrades, etc.) 4. It seems like people are mostly OK with the specific changes proposed in https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing . (Or at least, there haven't been a ton of inline comments there? That seems like enough agreement for me to start working on the specific changes proposed in the spreadsheet. I've got an operator release on my plate for this week, but I'll start on API changes as soon as that's wrapped up. (That'll give people more time to give feedback on the proposed changes as well). Thanks all! Jason On Sat, Jul 23, 2022 at 9:11 PM Gus Heck <gus.h...@gmail.com> wrote: > > On Sat, Jul 23, 2022 at 1:38 PM Shawn Heisey <apa...@elyograg.org> wrote: > > > On 7/23/2022 9:41 AM, Gus Heck wrote: > > > There is something of a risk to have a server that accepts non safe get > > > requests. All these requests are contrary to the HTTP specification ( > > > https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1). > > > > If the only way to make certain things happen with a GET is via the > > admin UI, then I think we can close that vector by turning the admin UI > > off by default and requiring a config option to enable it, probably in > > solr.xml. > > > The admin UI is definitely not required presently to make > persistent changes to solr. The the V1 api is get request based. Only if > one were to turn off v1 (i.e. deconfigure it's servlet in a hypothetical > future) would that become true. If we were to try to turn various versions > of the API's or feature areas on and off it would imply yet another if > check for yet another system property or some such that runs on every > request. Much better if the inherent dispatch of the server started the > request off in a servlet focused on that feature (or returned 404). > > As I think was mentioned previously in another discussion where I brought > this up we do have some difficulty with the order of some of our api > commands because the collection is part of the url ahead of the verb that > would normally denote the servlet i.e. we have /solr/collection1/update > instead of /solr/update/collection1 so some URL remapping for back compat > might become necessary, but that's an easily solved problem I think. > (jetty.xml is already using the rewrite handler for other things, so that > might be a place to start) > > -Gus > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
