[
https://issues.apache.org/jira/browse/SOLR-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138129#comment-18138129
]
Lucas Kot-Zaniewski commented on SOLR-18615:
--------------------------------------------
Thanks Eric. Right, this wouldn't touch any APIs: the {{cacheControl}}
init-param only applies to the {{static}} {{ResourceServlet}}, which is mapped
to the UI asset paths ({{/partials/}}, {{/libs/}}, {{/css/}}, {{/js/}},
{{/img/}}, {{/templates/}}, {{/ui/}}). All request handlers, including v2
{{/api/}}, go through {{SolrServlet}} and keep their {{<httpCaching>}}-driven
headers from solrconfig.xml. {{/ui/}} covers the new UI too, which benefits the
same way.
Browsers still keep their copy; they just revalidate on each full page load and
get a {{304}} with no body when nothing has changed, so the cost is a round
trip per asset on reload, not a re-download.
I'll put up a PR with option 2 plus the missing cache-buster on
{{libs/solr/index.js}} (harmless with no-cache, but keeps index.html
consistent), and a BATS test asserting the header.
> Admin UI shows error banners after upgrade
> ------------------------------------------
>
> Key: SOLR-18615
> URL: https://issues.apache.org/jira/browse/SOLR-18615
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
> Affects Versions: 10.1
> Reporter: Lucas Kot-Zaniewski
> Priority: Major
>
> After upgrading to 10.1, a browser that previously loaded the Admin UI from
> an older Solr at the same host:port can render a broken page showing the
> "SolrCore Initialization Failures" banner (with no cores listed) together
> with "Permission failure: Your user does not have the necessary role(s)". No
> 403 is returned by the server and no security is configured. A hard reload
> fixes it. Reported on the 10.1.0 RC3 vote thread:
> [https://lists.apache.org/thread/ycovoo72ssyxnskvyv3800kcnrx6grln]
> h3. Cause
> * {{index.html}} loads {{libs/solr/index.js}} (the generated v2 JS client,
> SOLR-17062) without the {{{}?_=$\{version{}}}} cache-buster that SOLR-15621
> added to every other script and stylesheet.
> * In 10.1, SOLR-15752 moved the UI's startup calls onto that client
> ({{{}SystemV2.getNodeSystemInfo{}}}, {{{}CoresV2.getAllCoreStatus{}}},
> {{{}CollectionsV2{}}}, {{{}AliasesV2{}}}). The System API
> ({{{}/api/node/system{}}}, SOLR-16458) does not exist in the 10.0 client.
> * Static UI files are served by the {{static}} {{ResourceServlet}} in
> {{WEB-INF/web.xml}} with only a {{Last-Modified}} header (no
> {{{}Cache-Control{}}}, no {{{}ETag{}}}), so browsers may heuristically reuse
> a cached copy without revalidating.
> * Result: new {{app.js}} + old cached client -> {{new solrApi.SystemApi()}}
> throws -> {{MainController}} fails -> Angular never evaluates the {{ng-show}}
> flags, so all hidden header banners are displayed as raw text.
> h3. Proposed fix options
> Solution 1: Add {{{}?_=$\{version{}}}} to the {{libs/solr/index.js}} script
> tag (immediate fix, 10.1.x).
> Solution 2: Since the cache-buster depends on every contributor remembering
> it (the route templates under {{partials/*.html}} also lack it), consider
> making it unnecessary by adding a {{cacheControl=no-cache}} init-param to the
> {{static}} {{ResourceServlet}} in {{{}WEB-INF/web.xml{}}}. Verified locally
> on Jetty 12.1.14: responses then carry {{{}Cache-Control: no-cache{}}}, and
> revalidation of an unchanged file returns {{304}} with no body (via
> {{{}Last-Modified{}}}), while files from a different release return
> {{{}200{}}}.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
