[
https://issues.apache.org/jira/browse/SOLR-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139325#comment-18139325
]
ASF subversion and git services commented on SOLR-18615:
--------------------------------------------------------
Commit a2bfbf7fa29679e0919514514503b6c21e3a6951 in solr's branch
refs/heads/main from Luke Kot-Zaniewski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a2bfbf7fa29 ]
SOLR-18615 don't cache admin resources (#5300)
Admin UI static files are now served with `Cache-Control: no-cache`, so after
an upgrade the browser revalidates them instead of mixing in files cached from
the previous Solr version. Such mixing could break the UI, for example by
showing bogus "Permission failure" banners.
> 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
> Assignee: Lucas Kot-Zaniewski
> Priority: Critical
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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]
