Can we remove cookie management from the backend?

[rgaudin]

As far as I understand, libkiwix itself uses two cookies for similar features:

• userlang which holds a 2 letter language code to record requested UI language.
• filters which holds the latest query string for the filters

Those sole purpose is to support the JS Viewer by recording user preferences.

I would thus like to suggest to move cookie management to JS/Viewer because:

• The Viewer being entirely independent of the backend it makes sense to let it handle its user preference storage.
• Cookies are per-user and thus prevent us from caching properly in our varnish frontend (library.kiwix.org)

In order to cache kiwix-serve data, we have to remove the cookie:

• from the requests: kiwix-serve backend thus doesn't see the cookie and sends the initial one from Accept-Language
• from the response: causing https://github.com/kiwix/kiwix-tools/issues/632 because UI is set solely from the cookie (and not URL param/fragment contrary to filters). Can be reproduced by disabling cookies in browser.

I don't know about the implementation but given the description in #849, I don't see how any of this requires the use of the backend. The reader part of the viewer is obviously JS-only and i18n handled in i18n.js and the per-lang JSON files. I'm not sure about search results but since those include english text even on a french UI, I'd say it's not i18n ready. Should it be, it could still be called by the reader passing the language.

So, could we consider removing this cookie code from the backend and handling it all from JS?

[veloman-yunkan]

I think that it can be done. I used the userlang cookie mostly as a way of preserving the user preference, but Web Storage API is a more adequate mechanism. Given that the browser language preference can be found out from Javascript the cookie can be eliminated.

[kelson42]

Wonder indeed why it has been implemented that way! Supportive of this improvement.

@veloman-yunkan I have no opinion if Web Storage API is better than cookie, maybe that point can be discussed/argumented as well. What is important to me is that what is necessary to the viewer is handled with the viewer and not somewhere else.

[kelson42]

I have raised the priority as it has a concrete and significant user-impact.

[mgautierfr]

Well... even if I think it should be better to implement this without a cookie, I would like to mention that we inverse the problem here.

We have a software (kiwix-serve) working correctly which is deployed in a configuration where we remove a part of the storage used by the software (cookie). Then, of course, the software is not working. But I would say it is a problem of the deployment, not the software (whatever the purpose of this specific deployment or who (us) is deploying it)

I don't know how @veloman-yunkan estimate the workload for this. But it would be simpler to not remove cookies in varnish (at the cost of potential cache yes, but what is better ? cache or working functionality ?) and then come back to another/previous configuration once this is fixed and published.

[rgaudin]

I agree with @mgautierfr ; impact should be on our infrastructure and not users that's why I've changed the configuration accordingly. @kelson42 please confirm that's OK with you.

[kelson42]

@rgaudin @mgautierfr We should have feature AND caching working fine. For the rest, trust you to find the most elegant solution :)