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

bug
1

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?__ws=site.com

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
2

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
3

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
      end 
    end

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
4

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 …

2 Likes
5

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.

6

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

1 Like
7

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
8

@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!