feat(catalog): Etag cache implementation into catalog - [merged] #124

Closed benoitdm-oslandia closed 1 year ago

In GitLab by @nrevelant on Oct 14, 2022, 16:24

_Merges feat/catalogcache -> develop

support for PGFS_CACHE environment variable
etag cache implemented with active and passive mode
etag exchanges between clients and pg_featureserv are now Base64 encoded
tests implemented for etag management

close #51

In GitLab by @nrevelant on Oct 14, 2022, 16:49

added 1 commit

26d6c5ef - etag tests can now be launched sequentially

Compare with previous version

In GitLab by @nrevelant on Oct 14, 2022, 16:51

marked this merge request as ready

Au dessus des imports stp

les fonctions ne semblent pas être testée

supprimer les log.Info

Avant les imports

supprimer le code mort (partout)

avant les imports

devrait être au moins une constante, au mieux un paramètre de la conf

Je crois me souvenir qu'on avait dit que l'eTag serait un membre de la struct api.GeojsonFeatureData ?

Dans quel cas penses tu que cette fonction sera utilisée ?

est ce que cette fonction ne pourrait pas être une fonction outil dans cache.go ?

idem est ce que la comparaison de 2 strong etag ne pourrait pas être une fonction outil dans cache.go ?

a priori les headers ont toujours le même format et n'ont pas suivre les formats définis par le "Accept". Le header "Accept" n'est que pour le body.

je n'ai pas vérifié, mais si le header If-None-Match ou If-Match est mal écrit on doit vraiment retourner un BadRequest ??

Une dernière chose : si tu ne modifies pas le code d'un fichier, inutile de modifier juste la date du header (2019 --> 2022) ! Pourrais tu revert les fichiers modifiés dont tu as juste mis à jour la date du header stp ?

marked this merge request as draft

In GitLab by @nrevelant on Oct 17, 2022, 11:48

Commented on internal/data/cache_active.go line 17

ok

In GitLab by @nrevelant on Oct 17, 2022, 11:55

Commented on internal/service/db_test/handler_db_etag_test.go line 53

Tu parles de la vérification du fait qu'un etag strong est en Base64 ? Ici dans le test c'est peut-être mal nommé, car je vérifie au départ simplement l'encodage. Tu verrais une route dédiée au niveau de l'API pour vérifier un strong etag directement dans sa forme brute (base64) ?

In GitLab by @nrevelant on Oct 17, 2022, 11:56

Commented on internal/service/db_test/handler_db_etag_test.go line 120

Oui mais si le client réclame un format différent, on parle alors de représenation différente de la feature, et on parle donc de strong etag différent non ?

In GitLab by @nrevelant on Oct 17, 2022, 12:05

added 1 commit

8102fb3f - former go version 1.13 patch, copyright update

Compare with previous version

In GitLab by @nrevelant on Oct 17, 2022, 12:15

Commented on internal/service/db_test/handler_db_etag_test.go line 171

J'ai l'impression qu'on pourrait traiter la requête en l'état. Mais ça engendrerait de la charge un peu inutile côté serveur /base non ? Comment trancher ?

actuellement notre strong etag ne prend pas en compte le format requis par le client. C'est une information transmise sous la forme d'un header HTTP

Non je voulais dire que le processus qui prend en entrée une string (strong etag) et qui produit les différents élément du strong etag (incluant le weak) pourrait être une fonction dans cache.go

Selon la RFC, il faut répondre par un 412 :

An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the 412 (Precondition Failed) status code

In GitLab by @nrevelant on Oct 17, 2022, 14:02

Commented on internal/service/db_test/handler_db_etag_test.go line 171

J'ai l'impression dans la RFC 7232 que les réponses 412 seraient pour les requêtes conditionnées du type POST,PUT,DELETE, et 304 pour les GET/HEAD ?

https://www.rfc-editor.org/rfc/rfc7232.html#section-2.3 :

When If-None-Match is present, evaluate the If-None-Match
       precondition:

       *  if true, continue to step 5

       *  if false for GET/HEAD, respond 304 (Not Modified)

       *  if false for other methods, respond 412 (Precondition Failed)

In GitLab by @nrevelant on Oct 17, 2022, 14:03

Normalement c'est ok, et le commit concerné de ce amtin poussé.

In GitLab by @nrevelant on Oct 18, 2022, 09:58

Commented on internal/service/db_test/handler_db_etag_test.go line 120

Pour bien confirmer, actuellement la construction du strong etag a été décidée et implémentée de cette façon : <collection>-<srid>-<format>-<weakEtag> Est-ce qu'il faut en changer ?

In GitLab by @nrevelant on Oct 18, 2022, 10:01

Commented on internal/data/catalog.go line 81

Cette forme était due au fait que FunctionFeature renvoyait 3 elements (dont l'etag de la feature). Désormais l'etag intègre la structure api.GeojsonFeatureData. Donc je pense que la question n'a plus lieu d'être ?

In GitLab by @nrevelant on Oct 18, 2022, 10:01

Commented on internal/data/catalog.go line 52

Fait, je vais pousser cette modif

non c'est bon !

ok pour POST,PUT,DELETE ==> 304 et GET/HEAD ==> 412

c'est bon !

In GitLab by @nrevelant on Oct 18, 2022, 14:32

Commented on internal/service/db_test/handler_db_etag_test.go line 171

Ok, tu voulais bien dire l'inverse c'est ça ? POST,PUT,DELETE ==> 412 GET/HEAD ==> 304

oui !

In GitLab by @nrevelant on Oct 18, 2022, 16:50

Commented on internal/service/db_test/handler_db_etag_test.go line 171

400 Bad Request en cas d'Etag malformé

In GitLab by @nrevelant on Oct 18, 2022, 17:17

Commented on internal/data/cache_active.go line 35

Les deux focntions d'encodage ne sont pas encore testées, mais le seront une fois la route permettant d'extraire les éléments du string etag sera en place.