Recherche avancée

Sur d’autres sites (9340)

• Revision 423e8a9727 : Fix allocation of context buffers on frame resize The patch : https://gerrit.chr

  24 juillet 2014, par Adrian Grange

  Changed Paths :
   Modify /vp9/decoder/vp9_decodeframe.c

  
  
  Fix allocation of context buffers on frame resize

  The patch :
  https://gerrit.chromium.org/gerrit/#/c/70814/
  changed the test that determined whether the context
  frame buffers needed to be reallocated or not.

  The code checked for a change in total frame area
  to signal the need to reallocate context buffers.
  However, the above_context buffer needs to be
  resized i:xf only the width of the frame has increased.

  Change-Id : Ib89d75651af252908144cf662578d84f16cf30e6

• Revision 7788c62286 : Fix clang compiler warning in denoising_neon. Issue : https://code.google.com/p/

  23 juillet 2014, par Marco Paniconi

  Changed Paths :
   Modify /vp8/encoder/arm/neon/denoising_neon.c

  
  
  Fix clang compiler warning in denoising_neon.

  Issue : https://code.google.com/p/webm/issues/detail?id=829

  Change-Id : I580308f8aa4af194b5d8990a9692ebd18db68ee8

• Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

  14 février 2018, par Pierre-Aurélien Georges

  Bonjour,

  voici le contexte : le serveur web de mon hébergeur est mal configuré (et je n’ai malheureusement pas réussi à leur faire corriger le problème). Le site web [1] est accessible aussi bien en HTTP qu’en HTTPS, mais en allant sur /ecrire/ ?exec=info je vois que le serveur ne renseigne ni la variable $_SERVER[’HTTPS’] ni la variable $_SERVER["SCRIPT_URI"], et à vrai dire lorsque je compare sur ce serveur un phpinfo() en HTTP et un phpinfo() en HTTPS je vois qu’il y n’a strictement AUCUNE différence entre les deux, et qu’il est donc totalement impossible de savoir (côté serveur) si la requête a été faite en HTTP ou en HTTPS.

  Dans ce contexte bien précis, le code de la fonction url_de_base() situé dans /ecrire/inc/utils.php pose problème, car il se base sur le contenu de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"] pour choisir entre HTTP et HTTPS et il ne tient absolument pas compte du contenu du champ META, ce qui dans mon cas est bien dommage car j’y ai mis l’url en https:...

  La conséquence de tout ceci est qu’en HTTPS cela entraîne des problèmes d’affichage d’images et de CSS qui ne sont pas bien appliqués, cf. [2]. Sur ce forum, vous verrez que je ne suis pas le seul à avoir affaire à un serveur mal configuré de la sorte, et que nous sommes plusieurs à avoir ce même problème. La solution de bricolage donnée par un des participants du forum est de rajouter dans /config/mes_options.php les deux lignes suivantes :
  

  $_SERVER[’HTTPS’] = "on" ;
  $_SERVER[’SERVER_PORT’]=’443’ ;
  

  
  Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage et c’était pas évident de trouver cette astuce !

  Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ? En effet, lorsque META commence par "https://" ça veut dire que le serveur gère le HTTPS, et donc s’il ne renseigne pas les variables HTTPS et SCRIPT_URI et bien dans le doute mieux vaut générer des url de base en "https://" plutôt qu’en "http://" car si cette url de base se retrouve mentionnée au sein d’un fichier html ou css, et que le fichier en question est demandé en HTTP, ce n’est pas grave s’il contient des ressources en HTTPS, alors que le contraire pose problème (ne pas mettre de ressources en HTTP au sein d’une page en HTTPS !)