stylesheetコントローラーでArgumentError (TimeとStringの比較に失敗しました)

Apache をリバースプロキシとした、ごく一般的なサブフォルダ/リバースプロキシのセットアップを使用しています。

当初は安全でないアセットの問題があったため、ENV で force_https を設定しました。現在、stylesheets/color_definitions_light_7_1_6cfae4de9c47a1b8ed3d5748018236d10ea9107e.css?__ws=site.com のようなアセットを取得する際に、以下のエラーが発生しています。

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

さて、

を見ると、stylesheet_time は文字列のようです。そのため、その行を次のように変更すると

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

問題が解決します。最近この部分に影響するコミットは見当たらないため、現在どのように発生しているのか理解できません。

設定方法は次のとおりです。

    stylesheet_time = query.pick(:created_at)

:created_at は適切な日付になるはずです。基盤となる gem が変更されたのでしょうか?また、テストでこれが検出されなかったのはなぜでしょうか?

「いいね!」 1

これを修正するようです。

    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

to_date が真値のものを nil の日付に変換できる可能性があるようです。
いいえ、それも機能しません。最終的にはセクションを begin/rescue/end でラップしました。

このサブフォルダ/リバースプロキシサイトのみに影響しているのか、非常に混乱しています。

おそらく、次のようなものに関連している可能性があります。

      cache_time = request.env["HTTP_IF_MODIFIED_SINCE"]

そして、それが Apache から渡されていないか、無効な日付文字列が渡されているのかもしれません。

以前はそれに対して rescue nil がありましたが、それは 5 年前のことです。

また、キャッシュであるためデバッグが難しいと思います。デバッグするには、動作しているかどうかをテストするためにキャッシュをフラッシュする必要があるでしょう。

「いいね!」 1

サブフォルダ設定を使用している間も、同様の問題が発生しました。force_https設定をtrueに設定して、関連性のない混合コンテンツの警告を修正した後、問題は解消しました…

「いいね!」 2

しまった。これで解決すると思ったのに、すでに ymlDISCOURSE_FORCE_HTTPS: true が設定されている。

なぜこのサイトだけ問題が起きているのか、ますます混乱している。

「HTTPSを強制する」設定を管理インターフェースで変更しましたが、おそらく同じことでしょう。

「いいね!」 1

こんにちは!

ApacheではなくNGINXをリバースプロキシとして使用した場合に、全く同じ問題が発生しました。
解決策は見つかりましたか?

ちなみに、デスクトップ版でのみ失敗し、モバイル版では全く問題ありません。
リバースプロキシでバッファリングを無効にすることで回避しています。

「いいね!」 1

@pfaffman 3.1.0.beta3 から 3.1.0.beta2 にダウングレードしたところ、すべて問題なく完了し、現在は期待どおりに完璧に動作しています。

Discourse の経験が浅いため、何が問題だったのかを確認したり、特にサポートされていないインストールでバグを報告したりすることはできません。

しかし、私がお手伝いできることがあれば喜んで協力させていただきます!