ArgumentError (Vergleich von Time mit String fehlgeschlagen) im Stylesheet-Controller

Ich habe eine ziemlich typische Subfolder/Reverse-Proxy-Einrichtung mit Apache als Reverse-Proxy.

Zuerst gab es Probleme mit unsicheren Assets, also habe ich force_https in ENV gesetzt. Jetzt, wenn Assets wie stylesheets/color_definitions_light_7_1_6cfae4de9c47a1b8ed3d5748018236d10ea9107e.css?__ws=site.com abgerufen werden.

Vielleicht mache ich etwas Dummes, aber ich bekomme das:

ArgumentError (comparison of Time with String failed)
app/controllers/stylesheets_controller.rb:66:in `<='
app/controllers/stylesheets_controller.rb:66:in `show_resource'
app/controllers/stylesheets_controller.rb:19:in `show'
app/controllers/application_controller.rb:414:in `block in with_resolved_locale'
app/controllers/application_controller.rb:414:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:74:in `call'
lib/middleware/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:369:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:228:in `call'
1 „Gefällt mir“

Nun, wenn man sich das ansieht:

Sieht es so aus, als wäre stylesheet_time ein String. Daher löst die Änderung dieser Zeile zu

    if cache_time && stylesheet_time && stylesheet_time.to_date <= cache_time

das Problem. Ich verstehe nicht, wie es jetzt passiert, da ich keine kürzlichen Commits sehe, die dies beeinflussen.

So ist es eingestellt:

    stylesheet_time = query.pick(:created_at)

Es scheint, dass :created_at ein richtiges Datum wäre. Könnte sich ein zugrundeliegendes Gem geändert haben? Und wie wäre das nicht in Tests aufgefallen?

1 „Gefällt mir“

Hier ist, was es zu beheben scheint:

    if !cache_time.to_date.nil? && !stylesheet_time.to_date.nil? 
      if (stylesheet_time.to_date <= cache_time.to_date)
        return render body: nil, status: 304
      end 
    end

Es sieht so aus, als ob to_date etwas Wahrhaftiges in ein nil-Datum umwandeln kann, nehme ich an.

Nein. Das funktioniert auch nicht. Ich habe den Abschnitt schließlich in ein begin/rescue/end eingepackt.

Ich bin sehr verwirrt, wie dies nur diesen Unterordner/Reverse-Proxy-Site betreffen könnte.

Vielleicht hat es etwas mit

      cache_time = request.env["HTTP_IF_MODIFIED_SINCE"]

zu tun und vielleicht wird das von Apache nicht weitergegeben oder es kommt eine ungültige Datumszeichenfolge durch.

Früher gab es ein rescue nil dafür, aber das war vor 5 Jahren.

Und ich denke, es ist schwer zu debuggen, da es sich um einen Cache handelt. Um zu debuggen, müsste ich diesen Cache leeren, um zu testen, ob er funktioniert.

1 „Gefällt mir“

Ich hatte das gleiche Problem (auch bei der Einrichtung mit Unterordnern). Nachdem ich eine nicht damit zusammenhängende Warnung bezüglich gemischter Inhalte behoben hatte, indem ich die Einstellung force_https auf true gesetzt habe, verschwand das Problem …

2 „Gefällt mir“

Verdammt. Ich hatte gehofft, das würde mich retten, aber ich habe bereits DISCOURSE_FORCE_HTTPS: true in der yml.

Jetzt bin ich noch verwirrter, wie es nur diese eine Seite mit dem Problem gibt.

Ich habe die Einstellung „HTTPS erzwingen“ in der Admin-Oberfläche geändert, aber es ist wahrscheinlich dasselbe.

1 „Gefällt mir“

Hallo!

Ich habe genau das gleiche Problem mit NGINX anstelle von Apache als Reverse-Proxy.
Haben Sie eine Lösung gefunden?

Übrigens ist es nur mit der Desktop-Version fehlgeschlagen, mit der mobilen Version gab es überhaupt keine Probleme.
Ich umgehe es, indem ich das Buffering auf dem Reverse-Proxy deaktiviere.

1 „Gefällt mir“

@pfaffman Ich habe einfach von einer 3.1.0.beta3 auf 3.1.0.beta2 herabgestuft, alles lief reibungslos und funktioniert jetzt einwandfrei, wie es sollte.

Ich bin nicht erfahren genug mit Discourse, um zu überprüfen, was schief gelaufen ist oder einen Fehler zu melden, insbesondere bei einer nicht unterstützten Installation.

Aber wenn ich helfen kann, tue ich das gerne!