lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Bernstein <>
Subject Re: Capturing URL params for use within Streaming Expressions
Date Fri, 18 Oct 2019 20:42:46 GMT
I think it's fine to pass through parameters to the various stream sources.
Perhaps we should limit it to a set list of parameters to pass through just
so it limits the scope,

Joel Bernstein

On Wed, Oct 16, 2019 at 4:47 PM Houston Putman <>

> Streaming expressions allow for users to pass in any arbitrary URL params
> in the search streaming source. I'm looking to add the ability for certain
> streaming functions, maybe just "search()" but possibly more, to extract
> the extra URL params passed along in the streaming request.
> For example sending a request:
> http://localhost:8983/solr/example/stream?expr=search(collection1,
> q="*:*", fl="id", sort="id")&
> *shards.preference=shards.preference=replica.location:local*
> would be equivalent to:
> http://localhost:8983/solr/example/stream?expr=search(collection1,
> q="*:*", fl="id", sort="id",
> *shards.preference="shards.preference=replica.location:local"*)
> The beauty of URL params is that they can easily be overridden and
> checked, for example in a proxy between the user and solr. It is harder to
> do this with streaming expressions as the proxy would need to parse the
> expression and know the logic of the functions and sources.
> I'm open to discussion on whether the params able to be captured by the
> streaming function would need to be white-listed or black-listed. My idea
> is that this would be generically implemented through something like the
> StreamContext, so that any streaming function that wants to add this
> functionality is able to do so.
> Another option is to add a URL parameter such as
> *&* (
> *expr.override.<function>.<parameter>=<value>*). That way it's explicit
> that the user is trying to send options to the streaming expression, and
> extraneous URL params aren't accidentally captured when they were included
> for a different purpose.
> Anyways this would really help us for some uses cases, especially the
> replica routing options used in the example above. Really interested to see
> opinions on either of these options.
> - Houston Putman

View raw message