[
https://issues.apache.org/jira/browse/SOLR-14898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter reassigned SOLR-14898:
-----------------------------------------
Affects Version/s: 8.6.3
Assignee: Chris M. Hostetter
Priority: Blocker (was: Major)
[~munendrasn] - I think you're right, in the case of HttpSolrCall.remoteQuery
we should definitely "set" the response headers to match the remote node.
Ideally when as a "proxy" we shouldn't be "adding" anything to the response
that didn't come from the proxied node, so we could/should in theory not let
RewriteHandler (on nodeA) add those headers if when nodeA proxies to nodeB
(leave it to nodeB to set them) but in practice since we aren't a generalized
proxy we're a solr node handing off to another solr node it should be fine to
leave that as is.
I'm going to work up a patch with a fix and (hopefully) a simple cloud test -
i'd like to get a fix into 8.6.3 for this given how it contributes to causing
SOLR-14896.
> Proxied/Forwarded requests to other nodes wind up getting duplicate response
> headers
> ------------------------------------------------------------------------------------
>
> Key: SOLR-14898
> URL: https://issues.apache.org/jira/browse/SOLR-14898
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.6.3
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Blocker
>
> When Solr receives a request for a collection not hosted on the current node,
> HttpSolrCall forwards/proxies that request - but the final response for the
> client can include duplicate response headers - one header from the remote
> node that ultimately handled the request, and a second copy of the header
> added by the current node...
> {noformat}
> # create a simple 2 node cluster...
> $ ./bin/solr -e cloud -noprompt
> # ...
> $ curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE&name=solo&numShards=1&nrtReplicas=1'
> # ...
> # node 8983 is the node currently hosting the only replica of the 'solo'
> collection, and responds to requests directly...
> #
> $ curl -S -s -D - -o /dev/null http://localhost:8983/solr/solo/select
> HTTP/1.1 200 OK
> Content-Security-Policy: default-src 'none'; base-uri 'none'; connect-src
> 'self'; form-action 'self'; font-src 'self'; frame-ancestors 'none'; img-src
> 'self'; media-src 'self'; style-src 'self' 'unsafe-inline'; script-src
> 'self'; worker-src 'self';
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-XSS-Protection: 1; mode=block
> Content-Type: application/json;charset=utf-8
> Content-Length: 169
> # node 7574 does not host a replica, and forwards requests for it to 8983
> # the response the client gets from 7574 has several security related headers
> duplicated...
> #
> $ curl -S -s -D - -o /dev/null http://localhost:7574/solr/solo/select
> HTTP/1.1 200 OK
> Content-Security-Policy: default-src 'none'; base-uri 'none'; connect-src
> 'self'; form-action 'self'; font-src 'self'; frame-ancestors 'none'; img-src
> 'self'; media-src 'self'; style-src 'self' 'unsafe-inline'; script-src
> 'self'; worker-src 'self';
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-XSS-Protection: 1; mode=block
> Content-Security-Policy: default-src 'none'; base-uri 'none'; connect-src
> 'self'; form-action 'self'; font-src 'self'; frame-ancestors 'none'; img-src
> 'self'; media-src 'self'; style-src 'self' 'unsafe-inline'; script-src
> 'self'; worker-src 'self';
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-XSS-Protection: 1; mode=block
> Content-Type: application/json;charset=utf-8
> Content-Length: 197
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
