I think RewindableInput needs a scope on it for ActionController. I just tracked down an issue with Rack 1.0.1 and LSWS 4.0.X (for sure .6, .10 and .11, I'm guessing all of them) where it wasn't able to resolve where RewindableInput was coming from. I can't see an easy external way to rack to solve this?

Any reason why we use gsub instead of sub here?

Hi,

I'm having issues with this new session merging algorithm.

Since {}.merge doesn't make a deep copy, the modifications made on values of the session hash are also visible in the "old" version of the session. Thus when merging the session, no updates are found and the "cur" session is stored without any modification.

I hope this is clear enough to understand the issue. It didn't happen with the previous version of Rack::Session::Memcache.

Better stash and reuse that OpenSSL::Digest::SHA1.new
Go green, recycle! ;0)

Venti-Bold:Desktop vais$ ruby untitled.rb
Rehearsal ----------------------------------------------------------
SHA1 new on each call 0.100000 0.000000 0.100000 ( 0.107096)
SHA1 reference stashed 0.070000 0.000000 0.070000 ( 0.065437)
------------------------------------------------- total: 0.170000sec

                         user     system      total        real

SHA1 new on each call 0.100000 0.000000 0.100000 ( 0.106567)
SHA1 reference stashed 0.070000 0.000000 0.070000 ( 0.064624)
Venti-Bold:Desktop vais$

require 'benchmark'
require "openssl"
n = 10000
Benchmark.bmbm do |x|
x.report('SHA1 new on each call') do

n.times do
  OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, "secret", "data")
end

end x.report('SHA1 reference stashed') do

sha1 = OpenSSL::Digest::SHA1.new
n.times do
  OpenSSL::HMAC.hexdigest(sha1, "secret", "data")
end

end end

rtomayko: Excellent. I really like what you’re currently doing in the chunked transfer encoding and streaming areas of Rack.

Just out of curiosity, if it works with a StringIO, why doesn’t it work with $stdin directly?

Good, I’m glad it’s not just me. :)

I’ve already opened a ticket this morning. I just assigned it to you.

http://rack.lighthouseapp.com/projects/22435-rack/tickets/20-put-requests-only-get-query-string-parameters#ticket-20-3

I don’t know but I hate this line of code. Checking for PUT explicitly feels all wrong to me and I’m still not sure why we’re calling GET.update as opposed to GET.merge and memoizing. I’ll try to get a ticket open today on some of these issues.

Shouldn’t this be self.get? and not self.put? Most ‘PUT’ requests are actually done as ‘POST’ and this lines means that it will only read query strings and not form data.

Making it easy to piggy-back DELETE on GET may not be something we want to encourage. Some browsers and their plugins will prefetch links on a page to speed up the end user experience. Any pages with the delete links will cause the resource to be automatically deleted whenever it is loaded by such a browser.

A few years ago there was a problem with Rails and Google Web Accelerator. At first the blame was placed on GWA, until it was pointed out that using GET requests to change state is against the HTTP spec and existing conventions. Here’s some more information about the topic:

http://shiflett.org/blog/2006/dec/google-web-accelerator-debate

I would think that piggy-backing the DELETE method onto a GET would be more useful, as that would allow normal HTML links to delete resources, e.g. /reservations/2313?_method=delete.

http://code.google.com/apis/gdata/docs/2.0/basics.html#UpdatingEntry

There is a related conversation on this same commit on rack/rack:

http://github.com/rack/rack/commit/8b8690bcb7762cde729088c2abdacb610ebea1f7#comments

@manveru: I did some research and it appears that the reason for this header is that Safari 2 and Flash can’t set the HTTP method when doing AJAX requests.

My original thinking was: If someone is using a browser with a web form, they should set _method in the form. If someone is using an HTTP library or doing an AJAX request they should set the HTTP method explicitly. Allowing a third way to set the HTTP method is unnecessary, and a bad idea if they are able to set the HTTP method directly, because the explicitness helps intermediaries among other things.

I see now that my assumptions were wrong. I never thought XHR would be limited to just GET and POST in Safari 2 and Flash.

I think it’s a cleaner way, if you want to POST or PUT contents from a client that cannot specify the request method without using form encoding. IMHO very unlikely, the last time i saw this referenced was http://jjinux.blogspot.com/2008/12/books-restful-web-services.html

I know I’ve seen this convention elsewhere, but I’m wondering what the use case is?

Good call on making this a Set. Though, this could’ve been more succinctly written as: (100..199).to_set << 204 << 304

Ryan, I think this is a great idea. I hadn’t seen the no-transform Cache-Control directive before, but I can understand why it should be used. BTW I added a small comment on the implementation in that commit.

In later commits to Rack::Deflate I added a short-circuit so that any 1xx, 204 and 304 responses it would skip the handler. I think that’s where your test should go, since I don’t think we’d want to set the Vary header in this instance.

I was playing around with also having Deflator respect the no-transform cache control directive:

http://github.com/rtomayko/rack/commit/7fe3f43195603721b0c9abd93426c50213afe227

Thoughts?

Awesome.