[ 
https://issues.apache.org/jira/browse/SOLR-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138129#comment-18138129
 ] 

Lucas Kot-Zaniewski edited comment on SOLR-18615 at 11/4/26, 6:53 PM:
----------------------------------------------------------------------

[~epugh]  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.


was (Author: JIRAUSER312834):
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]

Reply via email to