SOLR 7.5 returns http response 304 to SOLR admin UI query - is this correct when httpCaching never304="true" is a set?
Hi All, I have recently upgraded to SOLR 7.5 from SOLR 4.10.3 and believe I have noticed a change in the way HTTP caching is operating. I have installed the vanilla SOLR 7.5 on Windows 2012 R2 I have run the techproducts example where the solrconfig includes : I have opened the SOLR admin UI on IE11 and run a query (*:*) against the techproducts core. If I re-execute exactly the same query from the UI by re-pressing the "execute query" button the results are exactly the same ( including the QTime value). Running IE11 in debug mode (F12) with "Always Refresh from server" switched OFF it appears the http response from SOLR is 304 (use cached results). If I change the IE11 "internet options/ temporary internet files/ check for newer versions of stored pages" from value "Automatically" to "Every time I visit the webpage" then repressing the "execute query" button returns http response 200 as expected. I was expecting the configuration to prevent 304's being returned from SOLR - is this a mistaken assumption? I need to ensure that a user will not get browser cached results when doing queries from the SOLR Admin UI. I can not change the IE11 browser internet options. Is there a way to ensure that the server always returns the latest results and does not allow browser caching to be used? Many Thanks, Guy Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE. This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
SOLR 7.5 returns http response 304 to SOLR admin UI query - is this correct when is a set?
Hi All, I have recently upgraded to SOLR 7.5 from SOLR 4.10.3 and believe I have noticed a change in the way HTTP caching is operating. I have installed the vanilla SOLR 7.5 on Windows 2012 R2 I have run the techproducts example where the solrconfig includes : I have opened the SOLR admin UI on IE11 and run a query (*:*) against the techproducts core. If I re-execute exactly the same query from the UI by re-pressing the "execute query" button the results are exactly the same ( including the QTime value). Running IE11 in debug mode (F12) with "Always Refresh from server" switched OFF it appears the http response from SOLR is 304 (use cached results). If I change the IE11 "internet options/ temporary internet files/ check for newer versions of stored pages" from value "Automatically" to "Every time I visit the webpage" then repressing the "execute query" button returns http response 200 as expected. I was expecting the configuration to prevent 304's being returned from SOLR - is this a mistaken assumption? I need to ensure that a user will not get browser cached results when doing queries from the SOLR Admin UI. I can not change the IE11 browser internet options. Is there a way to ensure that the server always returns the latest results and does not allow browser caching to be used? Many Thanks, Guy Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE. This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.