Why returning a single space when using "head :ok" for instance?
See discussion around it here: jquery doesn't call success method on $.ajax for rails standard REST DELETE answer - Stack Overflow
Hi,
That very response links to the explanation
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 Ichanged 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 
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 4where 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 areusually 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 youare 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, thatapplies 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 aroundwhether 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.