Ember CLI contrarie nginx

Installation
,
1

J’effectue donc une installation Docker non prise en charge.

Cela signifie exécuter Ember CLI dans son propre conteneur avec un volume partagé sur un port différent et un proxy, comme prévu, vers le serveur Rails.

Malheureusement, pour tous les actifs .css, j’obtiens un « Bad Gateway 502 » de curl et du navigateur lorsque je passe entièrement par HTTPS et le proxy inverse nginx.

Il semble qu’Ember CLI ajoute un en-tête Content-Length alors que transfer-encoding: chunked est déjà ajouté par le serveur Rails.

(Je peux vérifier la réponse de Rails et d’Ember en accédant à différents ports)

Cela ne viole pas officiellement la norme du protocole HTTP 1.1, je crois (il est censé être ignoré) :

« Si un message est reçu avec à la fois un champ d’en-tête Transfer-Encoding et un champ d’en-tête Content-Length, ce dernier doit être ignoré. »

… mais cela fait que nginx refuse et annonce un 502 et ne sert pas l’actif, donc c’est sans importance.

Je peux parcourir un fichier CSS avec curl directement vers le conteneur sur localhost, mais au niveau de nginx, il n’est PAS content :

upstream sent "Content-Length" and "Transfer-Encoding" headers at the same time while reading response header from upstream

Quelqu’un a-t-il des idées sur la façon d’empêcher Ember CLI de faire cela ou une solution de contournement ? Je suis surpris que ce ne soit pas un problème avec l’installation standard ? (car la chaîne de communication devrait être très similaire).

La version de Discourse est 2.8.9

En-tête dans le dock (coupes mineures pour la brièveté) :

< content-transfer-encoding: binary
< content-type: text/css; charset=utf-8
< referrer-policy: strict-origin-when-cross-origin
< set-cookie: __profilin=p%3Dt; path=/forum; HttpOnly; SameSite=Lax
< **transfer-encoding: chunked**
< Vary: Accept, Accept-Encoding
< x-content-type-options: nosniff
< x-discourse-route: stylesheets/show
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-xss-protection: 0
< content-encoding: null
< **Content-Length: 3055**
1 « J'aime »
2

Nous utilisons uniquement le proxy Ember CLI en développement. Dans une installation standard, les requêtes vont de l’utilisateur à NGINX, puis à Rails. Je suggérerais de s’en tenir à ce schéma ; nous n’avons pas conçu notre configuration Ember CLI pour une utilisation en production. Même si vous parvenez à la faire fonctionner (ce qui ne sera pas facile), il y aura probablement des problèmes de sécurité et/ou de performance.

6 « J'aime »
3

Ah, eh bien, cette installation est actuellement un hybride développement/production, elle a donc des variables d’environnement comme :

RAILS_ENV: development

même si elle a le https complet et nginx en façade.

Mais je pourrais changer cela en « développement » pour que les choses fonctionnent.

Oui, donc Ember CLI n’est vraiment pas prêt pour le grand public, à mon avis, et je m’en tiendrai à cela uniquement pour le « vrai » développement.

Merci pour cette information cruciale David, cela m’a fait gagner beaucoup de temps !

3 « J'aime »
4

OK, cette histoire, d’ailleurs, devient plus étrange.

J’ai deux installations, toutes deux des configurations de « développement », celle-ci et une autre qui est une configuration Ubuntu non-docker.

Je remarque que les appels à /stylesheets/ sur le serveur de développement non-docker n’incluent pas « Transfer-Ecoding: chunked » dans l’en-tête du serveur Rails et incluent à la place une valeur « Content-Length »… quelqu’un peut-il expliquer comment cela pourrait être différent ?

Mise à jour : cela pourrait être expliqué par https://stackoverflow.com/questions/29112728/when-does-rails-respond-with-transfer-encoding-vs-content-length

1 « J'aime »
5

Je vais écrire un petit plugin pour ajouter l’en-tête Content-Length aux réponses des feuilles de style, juste pour voir si je peux empêcher une réponse Transfer-Encoding: chunked.

Si quelqu’un connaît un moyen plus simple d’y parvenir, je suis tout ouïe !

(Pour information, cela ne sera utilisé qu’en développement et jamais en production).

1 « J'aime »
6

Voici une mise à jour à ce sujet.

J’ai réussi à tromper le système. J’ai forcé un en-tête Content-Length en remplaçant le StylesheetsController, ce qui empêche la réponse en mode “chunked”, contournant ainsi la mauvaise habitude d’Ember CLI et évitant l’allergie d’nginx aux spécifications non conformes.

La façon dont je suis arrivé à cette solution a été de remarquer une autre configuration Ember CLI/nginx sur HTTPS, où Rails avait choisi de ne pas envoyer les réponses de Stylesheet en mode “chunked” (quelqu’un sait pourquoi cela aurait pu être le cas ?). Cela m’a amené à essayer de forcer l’en-tête et, devinez quoi, ça a fonctionné !

Ceci n’est nécessaire qu’en développement, donc je ne suis pas trop inquiet.

2 « J'aime »
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.