ArgumentError (comparison of Time with String failed) in stylesheet controller

I have a fairly typical subfolder/reverse proxy setup with Apache as the reverse proxy.

First there were issues with insecure assets, so I forced_https in ENV. Now when retrieving assets like stylesheets/color_definitions_light_7_1_6cfae4de9c47a1b8ed3d5748018236d10ea9107e.css?

Maybe I’m doing something stupid, but I’m getting this:

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/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 Like

Well, looking at

It looks like stylesheet_time is a string, so changing that line to

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

solves the problem. I don’t understand how it’s happening now, as I don’t see any recent commits affecting this.

So here’s how it’s set:

    stylesheet_time = query.pick(:created_at)

It would seem like that :created_at would be a proper date. Could some underlying gem have changed? And how would this not have been caught in tests?

1 Like

Here’s what seems to fix it:

    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

It looks like it’s possible for to_date to turn something that’s truthy into a nil date, I guess.

No. That doesn’t work either. I ended up wrapping the section in a begin/rescue/end.

I’m very confused how this could be affecting only this subfolder/reverse-proxied site.

Maybe it has to do with

      cache_time = request.env["HTTP_IF_MODIFIED_SINCE"]

and maybe that’s not getting passed through from Apache or something–or some invalid date string is coming through.

There used to be a rescue nil on that, but that was 5 years ago.

And I think it’s hard to debug since it is a cache, so to debug I’d need to flush that cache to test if it’s working.

1 Like

I had the some problem (also while using the subfolder setup). After fixing an unrelated mixed content warning by setting the force_https setting to true, the issue went away …


Darn. I was hoping this was going to save me, but I already have DISCOURSE_FORCE_HTTPS: true in the yml.

Now I’m all the more confused how it’s just this one site with the issue.

I’ve changed the “force https” setting in the admin interface, but it is probably the same thing

1 Like

Hi !

I got the exact same issue with NGINX instead of Apache as reverse proxy.
Did you find a solution?

By the way it’s only failed with the Desktop version, no issue at all with the mobile version.
I by pass it by disabling the buffering on the reverse proxy

1 Like

@pfaffman I simply downgrade from a 3.1.0.beta3 to 3.1.0.beta2 everything went smoothly and works now perfectly as it should.

I not experienced enough with Discourse to check what went wrong or enter a bug, especially on a unsupported install.

But if I can be of any help I will be glad!