Why "head" won't send an empty response?

Why returning a single space when using "head :ok" for instance?

See discussion around it here: http://stackoverflow.com/a/12824527/557368

Hi,

That very response links to the explanation

http://stackoverflow.com/questions/3351247/how-to-return-truly-empty-body-in-rails-i-e-content-length-0

As to whether its still valid to do so is another question.

Cheers,

Anthony

I see… But working around a Safari’s bug doesn’t sound like a good
reason to me… Maybe that bug has been already fixed a long while
ago and maybe that Safari version with the bug hasn’t been used for
a while…

Maybe the proper solution by that time would be to create a config

option like:

config.support_buggy_safari = true

It could even be the default... But the final choice to support it

or not would come from the application developers.

It fixed an issue by creating another one with regards to how jQuery

handles empty responses in special ways…

For instance, suppose you intercept all JSON results setting a

global error handler. Suppose that handle will check if the error
response contains an error message in the JSON encoded response. But
for a destroy action, for instance, there’s nothing useful to
return, so “head :ok” is perfectly fine. And it would work if the
response was truly empty instead of a single space response…

Cheers,
Rodrigo.

Have you checked on Rails 4? I’m pretty sure I changed this.

Yeah, there's some sort of discussion/change around this recently, or
maybe an open pull talking about it.

    Have you checked on Rails 4? I'm pretty sure I

changed this.

If you changed this it was after the beta release, right? I'm saying

that because my application is using Rails 4 beta and renders a
single space…

By the way, this issue is still affecting my application under

production (I’m using an ugly workaround currently):

https://github.com/rails/rails/issues/9461

Best,

Rodrigo.

So I think I didn’t changed it yet, but it is on my TODO list.

About your issue, right now I can’t take a look. It is assigned to Guillermo and I know he is a busy person, so I don’t know when he will have time to fix it. If you need this fixed Please Do Investigate.

Currently I’m investigate yet another issues also related to assets
pipeline that are still affecting me and I still don’t have a
work-around.

For some reason some assets aren't being included in production

environment during precompilation :frowning: I’ll keep you informed as I
understand what is happening…

Just a wild guess - have you noticed the change in Rails 4 where assets in the vendor directory are no longer digested?

For example, if you have /vendor/assets/fonts/font-awesome.ttf or /vendor/assets/images/glyphicons.png, and if you used to reference them in SASS with font-url(font-awesome.ttf) and image-url(glyphicons.png), these will no longer work.

These helpers will generate a digested path (/assets/font-awesome-836gfkeucnekw5273.ttf) but because Rails 4 will no longer produce a digested copy of vendor-ed assets, you’ll get a 404 when your browser attempts to load them.

This change usually won’t affect JS and CSS, because they are usually concatenated by sprocket anyway, but if you have images and fonts files you reference in your SASS, then this would break things.

The solution is to either move them back to your /app/assets, use static URLs in your stylesheets/image tags (url(/assets/fonts/font-awesome.ttf)), or add /vendor/assets back to the configuration (which I can’t remember off the top of my head).

This bit me last week so I thought I’d share this in case you are running into the same problem.

Godfrey

    Just a wild guess - have you noticed the change in Rails 4

where assets in the vendor directory are no longer digested?

Thank you, Godfrey, but I never put my assets in the vendor

directory of my application. When I find myself needing a vendor
asset I create a gem for it when it doesn’t exist yet and use it as
an engine.

But I guess this is also valid for those gems... But anyway the

problem is happening on a gem that puts the custom assets in the lib
directory and I experience the issue as well.

    For example, if you have

/vendor/assets/fonts/font-awesome.ttf or
/vendor/assets/images/glyphicons.png, and if you used to
reference them in SASS with font-url(font-awesome.ttf) and
image-url(glyphicons.png), these will no longer work.

Good to know that but is this also true for assets in lib/assets

from engines/gems?

One of the problem is exactly this one. I use my common-dialogs gem.

There are some images referenced in common-dialogs.scss but it is
not copied to public/assets when I run “rake assets:clobber
assets:precompile”. And I require it on application.scss. And it
works under the develoment environment.

Another issue is that if I call "rake assets:precompile

RAILS_ENV=production" it doesn’t work complaining that it can’t find
jquery.js. When I inspect Rails.configuration.assets.paths it is
different (much smaller) when compared to simply running “rake
assets:precompile” without specifying the RAILS_ENV variable. My
settings work differently than a regular Rails application.

All sources under

config/environments/(production|test|development).rb point to
development.rb that contains a few lines to load the configuration
through a custom configurator class. We have way more than those
three environments and it is really hard to maintain all settings
from all separate environments by messing with all yaml and ruby
files scattered through the application and also remember what to
put under RAILS_ENV for each environment, which is very error prone.
So we have a config/settings.rb that is a symlink to some file under
config/settings/envname.rb that will then call the
MyApp::Application.configure block among other settings as database
name, MongoDB, Solr, Redis, etc.

So, it shouldn't make any difference what I use for RAILS_ENV and

this is intriguing me. Why config.assets.path is not complete when I
set RAILS_ENV to production? The paths are correct when I don’t set
the RAILS_ENV var. This is what I’m currently investigating to try
to understand what is happening.

    These helpers will generate a digested path

(/assets/font-awesome-836gfkeucnekw5273.ttf) but because Rails 4
will no longer produce a digested copy of vendor-ed assets,
you’ll get a 404 when your browser attempts to load them.

    This change usually won't affect JS and CSS, because they are

usually concatenated by sprocket anyway, but if you have images
and fonts files you reference in your SASS, then this would
break things.

    The solution is to either move them back to your /app/assets,

use static URLs in your stylesheets/image tags
(url(/assets/fonts/font-awesome.ttf)), or add /vendor/assets
back to the configuration (which I can’t remember off the top of
my head).

I'll try to find this configuration and add the "lib" directory to

see if it works here. Thank you very much!

    This bit me last week so I thought I'd share this in case you

are running into the same problem.

Much appreciated, Godfrey!

Cheers,

Rodrigo.

Ok, this specific one I fixed by removing the :assets group from the
Gemfile and putting all gems outside that block. That made the trick
to find all assets when RAILS_ENV=production is specified. Now I
need to understand why some assets aren’t being generated…

Short answer to one of your questions - yes, that applies to gems/engines as well. For example, see this and this, or the source of this change here and the related GH issues.

Anyway, let’s keep this thread on topic (discussion around whether to add a single space for safari compat). If you need more help on the assets thing you can email me directly, although I think my last two responses already covered pretty much everything I know about this change.

Godfrey

    Short answer to one of your questions - yes, that

applies to gems/engines as well. For example, see this
and this ,
or the source of this change here and
the related GH issues.

Excelent, Godfrey! You're the man!

Adding those image extensions to config.assets.precompile did the

trick! Thank you so much!

      Anyway, let's keep this thread on topic (discussion around

whether to add a single space for safari compat). If you need
more help on the assets thing you can email me directly,
although I think my last two responses already covered pretty
much everything I know about this change.

Sure, sorry, I won't post more about the assets precompilation issue

in this thread (or any other since it is fixed now).

But I also believe this thread about "head" is over too as Rafael

already stated that he intends to remove the single space from the
head responses before Rails 4 final release if I understood
correctly…

Cheers,

Rodrigo.