+1 to the general "aspirations" from David's initial email. On the v1 vs. v2 question, I think it's a matter of level-of-effort. If there's bandwidth and energy to bring these ideals back to v1 and we find creative backwards-compatible ways to do it - that's great! But we're describing a decent amount of work here, and we as a community aren't flush with bandwidth, so it may make sense to prioritize the APIs we see sticking around longer-term.
> Furthermore, some handlers (e.g. SearchHandler) may be written/configured > to enforce read-only, even if POST is used (e.g. due to big queries). I > want to configure /stream handler as read-only but cannot do so today. Have y'all seen the new "QUERY" Http method? I stumbled on this (I think Ken L shared it somewhere) earlier this year, but it seems tailor-made for replacing our "POST" usage in SearchHandler: https://www.rfc-editor.org/info/rfc10008/ Best, Jason On Wed, Sep 16, 2026 at 11:30 AM David Smiley <[email protected]> wrote: > > I don't see these goals as specifically linked to v2. Someone sloppily > using GET inappropriately today (which happens all over the place, I'm > aware) can and should stop. It's not unreasonable to fail such requests > (GET requests performing modifications) in a minor release for better > security. The underlying infra shouldn't have to do with v1 vs v2. I > propose that the "read-only" constraint should be a first class property of > the SolrQueryRequest. Any place where a new SQR is created must be updated > carefully to propagate this—perhaps as a mandatory constructor argument. > Same for the collection/alias scoping. It shouldn't matter if > V2HttpSolrCall or HttpSolrCall builds the SQR. We'll need to ensure that > both pieces info ride on federated requests somehow (e.g. shard fan-out is > always POST but ought to articulate read-only somehow). Maybe HTTP headers. > > On Wed, Sep 16, 2026 at 10:56 AM Eric Pugh <[email protected]> > wrote: > > > I think this is a VERY feasible constraint that we could add to our V2 > > apis. I know less about the query apis. I don't think we should worry > > about the v1 APIs, they are what they are, and they should be retired. > > > > One way to make that happen is to add that explicitly to > > https://github.com/apache/solr/pull/4826. As I'm going through V2 apis I > > am referencing this document. It has also found other gaps like not all V2 > > apis treat an error the same way. At some point we'll be able to review > > all our V2 apis for "Do they all do things the same way", like GETs don't > > mutate things. > > > > On Wed, Sep 16, 2026 at 9:55 AM Jan Høydahl <[email protected]> wrote: > > > > > Big +1 > > > > > > Some of these could even land in 10.x with a clear explanation why in > > > upgrade notes. > > > > > > And the whole V1 API legacy also allows mutation on get, should start > > > deprecating those and eventually remove as their V2 couterpart gets > > stable. > > > Don't need to graduate all V2 APIs in the same release. > > > > > > Jan > > > > > > > 16. sep. 2026 kl. 04:05 skrev David Smiley <[email protected]>: > > > > > > > > I have a wish-list I want to share for better security defaults. > > Perhaps > > > > Solr 11 if not sooner. > > > > > > > > (A) HTTP GET is purely read-only. The request is retry-able. Under no > > > > circumstances, not even some delegating request, should a GET ever > > result > > > > in an index state mutation or a change to the cluster shape. For > > example > > > a > > > > GET to /solr/coll/stream (streaming expressions) should be forbidden > > from > > > > using streaming expressions that update an index. > > > > > > > > Furthermore, some handlers (e.g. SearchHandler) may be > > written/configured > > > > to enforce read-only, even if POST is used (e.g. due to big queries). I > > > > want to configure /stream handler as read-only but cannot do so today. > > > > > > > > (B) A collection-scoped request is isolated/firewalled to that > > > collection. > > > > A request to /solr/foo/whatever can only interact with the "foo" > > > collection > > > > (or any of its cores), or, if it points to an alias for multiple > > > > collections, it must be scoped to those collections. I understand we > > have > > > > useful capabilities to break free, even to another cluster, but such > > > > capabilities should be opt-in (i.e. an admin *must* _do something_ to > > > allow > > > > for that). The _something_ would be a solr.xml or sys-prop/env-var > > > change, > > > > NOT a configset change (at least not only). > > > > > > > > As we accomplish such aspirational goals, we then update the threat > > model > > > > https://github.com/apache/solr/blob/main/THREAT_MODEL.md > > > <https://github.com/apache/solr/blob/main/THREAT_MODEL.md> > > > > > > > > The above two rules would allow an org to configure simple GET-only > > > proxies > > > > at certain paths and easily reason about what they are exposing. > > > > > > > > I'm tempted to create 11.0 blocker umbrella issues for both. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's pretty remarkable what we allow, especially via streaming > > > > expressions. A request to /solr/fooCollection/stream is in no way > > scoped > > > > to that collection. to use expressions that (A) write data (e.g. vi > > > > to (A) mutate data (e.g. "update", expressions that communicate with > > > > > > > > ~ David Smiley > > > > Apache Lucene/Solr Search Developer > > > > http://www.linkedin.com/in/davidwsmiley > > > <http://www.linkedin.com/in/davidwsmiley> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > Disclaimer > > > > The information contained in this communication from the sender is > > confidential. It is intended solely for use by the recipient and others > > authorized to receive it. If you are not the recipient, you are hereby > > notified that any disclosure, copying, distribution or taking action in > > relation of the contents of this information is strictly prohibited and may > > be unlawful. > > > > This email has been scanned for viruses and malware, and may have been > > automatically archived by Mimecast, a leader in email security and cyber > > resilience. Mimecast integrates email defenses with brand protection, > > security awareness training, web security, compliance and other essential > > capabilities. Mimecast helps protect large and small organizations from > > malicious activity, human error and technology failure; and to lead the > > movement toward building a more resilient world. To find out more, visit > > our website. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
