[Rails-core] "X-CSRF-Token" HTTP header, added by jquery-rails

I was reading thru the security guide and working on some basic ajax... I thought it might be worth a mention in the guide that we don't need to set the X-CSRF-Token header when we create an ajax call. It is mentioned, but not very clear. I had to dig into rails

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

I wrote this in that mentioned issue on GitHub: " I tried disabling ETag and ConditionalGet middlewares but couldn't get any luck either in development or production environments." So, I don't think the development environment is the reason in this case. I'd love to hear about more wild guess

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

Completely wild guess, but the issue you're seeing could be related to the fact that you're running in development mode. I wouldn't trust any benchmark unless the app was in production mode. One reason is the code reloading in development mode. Allen Madsen http://www.allenmadsen.com On Wed, Feb

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

I've created this issue in GitHub: https://github.com/rails/rails/issues/14117 Here's a sample application: https://github.com/rosenfeld/rails-template-streaming-bug And you can see it live on OpenShift here: http://railstemplatestreamingbug-rosenfeld.rhcloud.com/ It would be interesting to

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

I didn't know you could turn off caching in chrome. I'll have to take a better look into their dev tools. Once you figure this out, it could make a nice blog post on how to use front end + backend analytics to debug and speed up performance problems. On Wed, Feb 19, 2014 at 12:02 PM, Rodrigo Rose

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

On 19-02-2014 13:44, richard schneeman wrote: This functionality does not come from Rails, but rather Rack::Runtime (http://guides.rubyonrails.org/configuring.html#configuring-middleware) you can see the middleware here: https://github.com/rack/rack/blob/master/lib/rack/runtime.rb. It looks pr

Re: [Rails-core] X-Runtime header doesn't seem to be reliable

This functionality does not come from Rails, but rather Rack::Runtime ( http://guides.rubyonrails.org/configuring.html#configuring-middleware) you can see the middleware here: https://github.com/rack/rack/blob/master/lib/rack/runtime.rb. It looks pretty simple, i'm not sure if it is streaming aware

Re: [Rails-core] Was 4.0.3 taged/released correctly or did something go wrong?

4.0.3 is a security update. To make it easy to apply security fixes, we try to make these security updates as minimal as possible.  The other bug fixes originally scheduled for 4.0.3 are pushed to 4.0.4.  Godfrey — Sent from Mailbox for iPhone On Wed, Feb 19, 2014 at 3:45 AM, Adrien Siami

[Rails-core] X-Runtime header doesn't seem to be reliable

As far as I understand, Rails uses a middleware by default that will send the total time spent on a request in the Rails side in the X-Runtime HTTP header. But it doesn't seem to be reliable in the sense that when I perform a request against http://localhost:3000/ (development environment, tes

[Rails-core] Was 4.0.3 taged/released correctly or did something go wrong?

According to semantic versioning, this is perfectly normal. Updating to a 4.0.x should be straight forward. This was not respected when updating from 4.0.0 to 4.0.1, it was a real pain to update. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: C

Re: [Rails-core] Was 4.0.3 taged/released correctly or did something go wrong?

> On 19 Feb 2014, at 08:30, Jarl Friis wrote: > > From: > https://github.com/rails/rails/issues/12808#issuecomment-35476010 > > To be honest I think something went wrong when tagging v4.0.3. > > > $ git log --oneline v4.0.2..v4.0.3 | wc -l > 3 > $ git log --oneline v4.0.2..origin/4-0-stabl

[Rails-core] Was 4.0.3 taged/released correctly or did something go wrong?

From: https://github.com/rails/rails/issues/12808#issuecomment-35476010 To be honest I think something went wrong when tagging v4.0.3. $ git log --oneline v4.0.2..v4.0.3 | wc -l 3 $ git log --oneline v4.0.2..origin/4-0-stable | wc -l 266 v4.0.3 only contains three commits not found in