[keycloak-dev] Improve browser caching?
Marek Posolda
mposolda at redhat.com
Wed Feb 4 03:11:36 EST 2015
On 4.2.2015 08:55, Stian Thorgersen wrote:
> https://issues.jboss.org/browse/KEYCLOAK-1017 ;)
>
> I was thinking it would be cleaner to add it to the URL of theme resources.
>
> /auth/theme/.../<VERSION>/stylesheet.css
>
> This works better for relative URLs.
+1
>
> Not sure I like using the release version, we could have a short hash or just an incrementing number.
Sure, we can use whatever of this. Hash might have an advantage that can
be generated at compile time though. So it's even better for us during
development as version is still "1.2.0.Beta1-SNAPSHOT" but hash will
always change (not sure about KeycloakServer, which is usually executed
directly from IDE and bypasses maven, but maybe there is some solution
for this too).
Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 3 February, 2015 11:00:07 PM
>> Subject: [keycloak-dev] Improve browser caching?
>>
>> We seem to have many questions each release related to non-working
>> things due to stale browser cache. Usually it's due to changes in admin
>> console, but it may be even worse if we ever change something in CSS/JS
>> of login or account mgmt, as those are available for end users.
>>
>> I wonder if we can somehow improve this? One possible solution is to
>> attach the redundant parameter with version to the cached resources.
>> Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
>> upgrade to next version will force browser to reload the resource.
>>
>> The problem is longer (and not so nice) URLs and also some refactoring
>> needed. For freemarker templates, we can add version parameter at
>> runtime. However for admin console HTML pages, we would need to add
>> version somehow at compile time though.
>>
>> There is also possibility to attach hash instead of version (Juca
>> mentioned this to me some time ago), but not sure if it's big difference.
>>
>> Any better ideas? Or should we rather just keep it as it is?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
More information about the keycloak-dev
mailing list