You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2020/09/28 17:12:00 UTC

[jira] [Assigned] (SOLR-14898) Proxied/Forwarded requests to other nodes wind up getting duplicate response headers

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org