Affichage "indisponibilité" d'une resource suite à un changement de 'resource_url'

[Brewennn]

Salut,

Nous avons reçu un mail de Sète nous indiquant que le jeu théorique est indisponible bien qu'on puisse télécharger le fichier zip (JDD : ici).

Ce problème est survenu à la suite d'une modification de l'URL à laquelle se trouve la ressource, stockée sur désormais sur google drive. Etant donné qu'il s'agit du seul jeu de données issu de google drive, je fais l'hypothèse que ce ne soit pas adapté à transport.data.gouv.fr.

Sinon, j'ai vu qu'il y avait déjà eu des discussions sur autour du choix de l'URL pour afficher la disponibilité des JDD : #2495

[Brewennn]

@etalab/transport-tech, une personne peut-elle regarder vite fait pour savoir si j'ai une action à faire de mon côté ou s'il y a bien une erreur technique de notre côté svp ?

[thbar]

@Brewennn je jette un oeil !

[thbar]

Ressource: https://transport.data.gouv.fr/resources/81575

[Brewennn]

Merci car on me relance sur le sujet. Le ressource est marquée comme indisponible mais on peut la télécharger et accéder au rapport de validation.

[thbar]

[thbar]

Une hypothèse que j'avais était que ça aurait pu être lié à une obligation de télécharger via un navigateur, mais ce n'est pas le cas, curl y parvient:

❯ curl --location -O "https://drive.google.com/uc?export=download&id=1JPmGimO4tfQpzL8A0ixYnYrPDehYILWn"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  548k  100  548k    0     0   168k      0  0:00:03  0:00:03 --:--:--  178k

transport-site/ttmp on  master [$?] 
❯ unzip uc
Archive:  uc
  inflating: agency.txt              
  inflating: calendar.txt            
 extracting: calendar_dates.txt      
  inflating: routes.txt              
  inflating: shapes.txt              
  inflating: stops.txt               
  inflating: stop_times.txt          
  inflating: trips.txt               

[thbar]

Je reproduis le souci dans les couches plus basses. C'est une requête head avec redirection, elle fonctionne si on utilise curl, mais pas si on utilise HTTPoison, qui est utilisé pour le calcul de disponibilité:

iex(8)> Transport.Shared.Wrapper.HTTPoison.impl().head(url, [], follow_redirect: true)
{:error,
 %HTTPoison.Error{
   reason: {:invalid_redirection,
    {:ok, 303,
     [
       {"Content-Type", "application/binary"},
       {"Cache-Control", "no-cache, no-store, max-age=0, must-revalidate"},
       {"Pragma", "no-cache"},
       {"Expires", "Mon, 01 Jan 1990 00:00:00 GMT"},
       {"Date", "Wed, 14 Aug 2024 16:52:44 GMT"},
       {"Location",
        "https://drive.usercontent.google.com/download?id=1JPmGimO4tfQpzL8A0ixYnYrPDehYILWn&export=download"},
       {"Content-Length", "0"},
       {"Strict-Transport-Security", "max-age=31536000"},
       {"Content-Security-Policy",
        "require-trusted-types-for 'script';report-uri /_/DriveUntrustedContentHttp/cspreport"},
       {"Content-Security-Policy",
        "script-src 'report-sample' 'nonce-SGjG6xdNxsGFWmrL0LjIAA' 'unsafe-inline';object-src 'none';base-uri 'self';report-uri /_/DriveUntrustedContentHttp/cspreport;worker-src 'self'"},
       {"Permissions-Policy",
        "ch-ua-arch=*, ch-ua-bitness=*, ch-ua-full-version=*, ch-ua-full-version-list=*, ch-ua-model=*, ch-ua-wow64=*, ch-ua-form-factors=*, ch-ua-platform=*, ch-ua-platform-version=*"},
       {"Cross-Origin-Opener-Policy", "same-origin"},
       {"Accept-CH",
        "Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Full-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Model, Sec-CH-UA-WoW64, Sec-CH-UA-Form-Factors, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version"},
       {"Server", "ESF"},
       {"X-XSS-Protection", "0"},
       {"X-Frame-Options", "SAMEORIGIN"},
       {"X-Content-Type-Options", "nosniff"},
       {"Alt-Svc", "h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000"}
     ],
     {:client, {1723, 654364, 22284}, {:metrics_ng, :metrics_dummy},
      :hackney_ssl, ~c"drive.google.com", 443, "drive.google.com",
      [follow_redirect: true],
      {:sslsocket, {:gen_tcp, #Port<0.498>, :tls_connection, :undefined},
       [#PID<0.18405.0>, #PID<0.18404.0>]},
      {:default, #Reference<0.3295491388.1269301249.113019>,
       {:connection, :hackney_ssl, ~c"drive.google.com", 443, 128679357, false},
       #PID<0.18346.0>, :hackney_ssl},
      #Reference<0.3295491388.1269301249.113019>, true, :hackney_pool, 5000,
      true, 5, false, 5, nil, nil,
      {:hparser, :response, 4096, 10, 0, :on_body, "", {1, 1}, "", [], 0, "",
       "", "application/binary",
       "https://drive.usercontent.google.com/download?id=1JPmGimO4tfQpzL8A0ixYnYrPDehYILWn&export=download",
       :waiting},
      {18,
       {:dict, 17, 16, 16, 8, 80, 48, {[], [], [], [], [], [], [], [], [], ...},
        {{[
            ["content-length", {6, "Content-Length", "0"}],
            [
              "cross-origin-opener-policy",
              {11, "Cross-Origin-Opener-Policy", ...}
            ]
          ],
          [
            ["location", {5, "Location", ...}],
            ["strict-transport-security", {7, ...}]
          ], [["date", {4, ...}], ["x-content-type-options", {...}]],
          [["expires", {...}]], [], [[...]], [], ...}}}}, :connected, :waiting,
      nil, :normal, false, false, false, :undefined, false,
      &:hackney_request.send/2, :waiting, nil, 4096, "", [], {1, 1}, 0, nil,
      nil, ...}}},
   id: nil
 }}

[thbar]

@Brewennn je penche pour un bug dans une de nos dépendances. Il y a une "redirection d'url" que la librairie utilisée estime comme étant invalide.

Je creuse pour une reproduction.

[thbar]

@Brewennn pourras-tu les prévenir qu'on a identifié le souci, mais que c'est une situation nouvelle effectivement (liée à Google Drive comme tu l'as identifié) et que le délai de correction reste à définir ? Merci !

(je tenterai de regarder à nouveau vendredi)

[thbar]

En lien avec soucis déjà identifiés, mais dont le correctif n'agit pas sur le cas précis qu'on observe:

• https://github.com/etalab/transport-site/issues/3463
• https://github.com/etalab/transport-site/pull/3464
• https://github.com/edgurgel/httpoison/issues/171
• https://github.com/edgurgel/httpoison/issues/322

[thbar]

Ok je vois comment faire, je me pencherai dessus vendredi matin.

[thbar]

@etalab/transport-tech j'ai implémenté un hot-fix ici:

• https://github.com/etalab/transport-site/pull/4127

Je serai en congés et @Brewennn également sauf erreur, pourrez-vous prendre le relais et notifier Sete ?

Merci !

[ptitfred]

La ressource est à nouveau indiquée comme disponible :

Il me reste à nettoyer l'historique pour ne pas fausser les statistiques du producteur.

[ptitfred]

J'ai répondu à l'AOM.

[ptitfred]

Il me reste à nettoyer l'historique pour ne pas fausser les statistiques du producteur.

Fait avec delete from resource_unavailability where id = 100963;

Pour mémoire il y avait avant:

> select * from resource_unavailability where id = 100963;
id          | 100963
resource_id | 81575
start       | 2024-08-08 15:05:16
end         | 2024-08-19 07:29:53
inserted_at | 2024-08-08 15:05:16.065208
updated_at  | 2024-08-19 07:29:53.953689

[ptitfred]

Je n'ai pas touché aux données historiques (dataset_score) présentées dans le graphique ci-après car il y a du calcul de moyennes flottantes dont le recalcul serait non trivial.

[thbar]

Merci @ptitfred !