Back in 2019, devmchakan was able to add my <e@80x24.org> email address to their GH account since there was no confirmation process. I am not devmchakan and do not know who they are. Obviously, I (Eric Wong) am infamous for being anti-GH and would never put code on their gamified proprietary platform. Despite my disdain for GH, I was able to open a ticket with GH support (ticket #712018) in June 2020 and get my email address removed from devmchakan's account. I actually don't care to take credit for my work nor do I even care if other people taking credit for my work. However, my name and email address are already on the commits in question; and I am EXTREMELY against having anything I do associated with a gamified proprietary platform. The commits in question are: 64349662ac18 (webrick: remove concurrent-ruby dev dependency, 2017-12-29) 55500f93e6da (webrick: detect partial hijack without hash headers, 2016-05-12) bcf2698bcc90 (Revert "Add 205 Reset Content to the list of statuses without a message body", 2016-12-14) d6380043a895 (deflater: remove "deflate" encoding support, 2016-07-26) --- If you prefer pull requests: The following changes since commit bc7f8d8a7fc73a15e98bfb86a231602fca255fda: Fix possible thread safety issue in Rack::Session::Pool (2022-01-25 14:38:35 -0800) are available in the Git repository at: https://80x24.org/rack.git misattribute for you to fetch changes up to 2734f39d84807dc7e84be46f7b966fb5461bf2d6: fix misattributed entries in CHANGELOG (2022-12-24 07:49:09 +0000) ---------------------------------------------------------------- Eric Wong (1): fix misattributed entries in CHANGELOG CHANGELOG.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 3ed7442d..fbcd079c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -262,7 +262,7 @@ All notable changes to this project will be documented in this file. For info on - Improve performance of `Multipart::Parser` when uploading large files. ([@tompng](https://github.com/tompng)) - Increase buffer size in `Multipart::Parser` for better performance. ([@jkowens](https://github.com/jkowens)) - Reduce memory usage of `Multipart::Parser` when uploading large files. ([@tompng](https://github.com/tompng)) -- Replace ConcurrentRuby dependency with native `Queue`. ([@devmchakan](https://github.com/devmchakan)) +- Replace ConcurrentRuby dependency with native `Queue`. ### Fixed @@ -292,9 +292,9 @@ All notable changes to this project will be documented in this file. For info on ### Changed - Freeze default session options to avoid accidental mutation. ([@kirs](https://github.com/kirs)) -- Detect partial hijack without hash headers. ([@devmchakan](https://github.com/devmchakan)) +- Detect partial hijack without hash headers. - Update tests to use MiniTest 6 matchers. ([@tonytonyjan](https://github.com/tonytonyjan)) -- Allow 205 Reset Content responses to set a Content-Length, as RFC 7231 proposes setting this to 0. ([@devmchakan](https://github.com/devmchakan)) +- Allow 205 Reset Content responses to set a Content-Length, as RFC 7231 proposes setting this to 0. ### Fixed @@ -307,7 +307,7 @@ All notable changes to this project will be documented in this file. For info on ### Removed -- Remove `deflate` encoding support to reduce caching overhead. ([@devmchakan](https://github.com/devmchakan)) +- Remove `deflate` encoding support to reduce caching overhead. ### Documentation -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20221224075808.GA3854%40dcvr.
Now that Rack::Chunked is gracefully a no-op for non-1.1 HTTP versions, do not cause unnecessary pain for end users upgrading to Rack 3. --- lib/rack/chunked.rb | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/rack/chunked.rb b/lib/rack/chunked.rb index 004163d9..b66f467b 100644 --- a/lib/rack/chunked.rb +++ b/lib/rack/chunked.rb @@ -4,8 +4,6 @@ require_relative 'constants' require_relative 'utils' module Rack - warn "Rack::Chunked is deprecated and will be removed in Rack 3.1", uplevel: 1 - # Middleware that applies chunked transfer encoding to response bodies # when the response does not include a content-length header. # -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20220901214536.5469-3-e%4080x24.org.
895beec0622d (chunked: do not chunk on pre-HTTP/1.0 clients, 2013-11-12) was written in 2013 in anticipation of HTTP/1.2 and future versions supporting chunked encoding. As of 2022, HTTP/1.2 is yet to happen, and is unlikely given HTTP/2 and HTTP/3 both exist. So limit chunking to HTTP/1.1, since HTTP/1.x will remain in use for years to come, and there's still a few odd places using HTTP/0.9. --- lib/rack/chunked.rb | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/lib/rack/chunked.rb b/lib/rack/chunked.rb index 47fb36ac..004163d9 100644 --- a/lib/rack/chunked.rb +++ b/lib/rack/chunked.rb @@ -83,16 +83,9 @@ module Rack @app = app end - # Whether the HTTP version supports chunked encoding (HTTP 1.1 does). + # Whether the HTTP version supports chunked encoding (only HTTP 1.1 does). def chunkable_version?(ver) - case ver - # pre-HTTP/1.0 (informally "HTTP/0.9") HTTP requests did not have - # a version (nor response headers) - when 'HTTP/1.0', nil, 'HTTP/0.9' - false - else - true - end + ver == 'HTTP/1.1' # HTTP/2 doesn't, and HTTP/1.2 is unlikely end # If the rack app returns a response that should have a body, -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20220901214536.5469-2-e%4080x24.org.
Lets reduce the pain on end users upgrading to Rack 3. HTTP/1.0 and HTTP/1.1 aren't going away, and I was dealing with HTTP/0.9 until 2017. Fwiw, probably 95% of people and organizations I know have given up on Ruby due to constant treadmill of upgrades and incompatibilities, so avoid giving them more reason to give up Ruby due to more incompatibilities. The following changes since commit 6aad5390403ca48a0ba76e426a21274385895731: The stream argument must implement `#<<`. (#1959) (2022-08-31 14:31:46 +1200) are available in the Git repository at: https://80x24.org/rack.git chunk for you to fetch changes up to e3945c3acc5a6e8d3af4cc8639dcb12fb85a8aee: chunked: remove deprecation warning (2022-09-01 21:34:23 +0000) ---------------------------------------------------------------- Eric Wong (2): chunked: limit to HTTP/1.1 chunked: remove deprecation warning lib/rack/chunked.rb | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20220901214536.5469-1-e%4080x24.org.
richard schneeman <richard.schneeman@gmail.com> wrote: > I personally think there is benefit to listing existing Rack servers in one > place for easy reference in case future developers want to see the source. > My personal preference would be to preserve some link to the project for > documentation purposes. Please reconsider. I don't have time to figure out MFA if it becomes popular, again. I remain anti-JavaScript and anti-GUI since I can't deal with the implementation complexity. Any more popularity of unicorn would just cause unnecessary friction and stress for both myself and new users. MFA or not, I'll gladly add backdoors to projects if bribed or threatened. Thanks. -----------8<----------- Subject: [PATCH] README: remove "Unicorn" reference The robustness of unicorn has unfortunately led to more and more unfixed bugs in other parts of the Rack ecosystem. Furthermore, development is unsustainable and I can't afford to support new users. --- README.rdoc | 1 - 1 file changed, 1 deletion(-) diff --git a/README.rdoc b/README.rdoc index d54b2b32..781fbb3f 100644 --- a/README.rdoc +++ b/README.rdoc @@ -29,7 +29,6 @@ These web servers include \Rack handlers in their distributions: * {Phusion Passenger}[https://www.phusionpassenger.com/] (which is mod_rack for Apache and for nginx) * Puma[https://puma.io/] * Thin[https://rubygems.org/gems/thin] -* Unicorn[https://yhbt.net/unicorn/] * uWSGI[https://uwsgi-docs.readthedocs.io/en/latest/] * Lamby[https://lamby.custominktech.com] (for AWS Lambda) -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20220709223010.GA9704%40dcvr.
[-- Attachment #1.1: Type: text/plain, Size: 1742 bytes --] Hey everyone, my name is Corey Farwell and I'm an engineer at Kickstarter. Years back in 2012, some Kickstarter engineers created the rack-attack <https://github.com/kickstarter/rack-attack>project, which is a Rack middleware for blocking and throttling abusive requests. We still utilize and rely on rack-attack, but due to staffing changes and reductions, we have not made any significant contributions to the project over the past few years. We are fortunate to have a volunteer in the community, Gonzalo Rodriguez <https://github.com/grzuy>, who has stepped up to maintain the project in our absence. At this point, I personally consider rack-attack to be a community-driven project, despite living within the Kickstarter GitHub organization. Fast forward to February of this year, Samuel Williams in Gitter <https://gitter.im/rack-attack/rack-attack?at=5e3f4e8919597421f3b97414>suggested moving the project to the rack GitHub organization. I ran this idea past the Engineering and Legal teams at Kickstarter and got the green light! Is this something y'all are interested in? Related– my last day at Kickstarter is in two weeks, so if we want this to happen, we might need to move a little fast :) Hope you all are doing okay during this tumultuous time Corey Farwell coreyf@rwell.org https://rwell.org/ -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/f1ab3420-df93-4f8c-8c72-920a163490d4n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 2185 bytes --]
richard schneeman <richard.schneeman@gmail.com> wrote: > To follow up on this in the email list. The link was changed in > https://github.com/rack/rack/commit/3eb4547bcb651f29addd05bf225f6ee009fca87b > to point at https://bogomips.org/unicorn/ and the patch has not been > applied. I do not know if there was other discussion outside of the link. I > don't have commit to master, but did stage you change at > https://github.com/rack/rack/compare/master...schneems:no-unicorn?expand=1 > before realizing the link had been updated. Thanks for the followup. But I prefer it point to https://rubygems.org/gems/unicorn because bogomips.org is likely going away once extortionists take over the .org TLD[*] I don't believe in paying .org extortionists out of principle (and also being a cheapskate :P). The folks running RubyGems.org are probably more likely to justify the cost, and I can update the gemspec to another URL without having to bother anybody here. > > But I really hate marketing and would rather not promote it at all. > > I personally think there is benefit to listing existing Rack servers in one > place for easy reference in case future developers want to see the source. > My personal preference would be to preserve some link to the project for > documentation purposes. I imagine most folks would rather shove unicorn under the rug due to my refusal to use centralized/proprietary services or JS :> [*] Fwiw I always expected something like the .org sell-out to happen, hence my choice to not build a "brand identity" around bogomips.org or any other name. No identity, nothing to lose :> -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20191219031625.GB3411%40dcvr.
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --] To follow up on this in the email list. The link was changed in https://github.com/rack/rack/commit/3eb4547bcb651f29addd05bf225f6ee009fca87b to point at https://bogomips.org/unicorn/ and the patch has not been applied. I do not know if there was other discussion outside of the link. I don't have commit to master, but did stage you change at https://github.com/rack/rack/compare/master...schneems:no-unicorn?expand=1 before realizing the link had been updated. > But I really hate marketing and would rather not promote it at all. I personally think there is benefit to listing existing Rack servers in one place for easy reference in case future developers want to see the source. My personal preference would be to preserve some link to the project for documentation purposes. -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/CAFA5uRMOKcYipoM0gz2x-yzT4hbsanKHXjxtr6RwT8%2Bq8e-OpQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 2850 bytes --]
unicorn does not and will never use proprietary software or any services requiring a terms-of-service or registration for development. Having a github.com URL there is misleading to potential users and hackers. See commit df1d52d4a8a303119879cb2fb7466049393afbe3 for rationale for the complete removal. --- If you really must have something, point it to rubygems.org/gems/unicorn But I really hate marketing and would rather not promote it at all. Thanks. The following changes since commit 49ed3267e4181b47fe53431be4805968eed81e3d: Merge pull request #1426 from osamtimizer/fix/eliminate-warnings-on-test (2019-12-14 10:11:15 +1300) are available in the Git repository at: https://80x24.org/rack.git no-unicorn for you to fetch changes up to 069b501fee065847d00671e5cbcd928224b6fd44: README.rdoc: remove incorrect URL for unicorn (2019-12-15 04:01:53 +0000) ---------------------------------------------------------------- Eric Wong (1): README.rdoc: remove incorrect URL for unicorn README.rdoc | 1 - 1 file changed, 1 deletion(-) diff --git a/README.rdoc b/README.rdoc index 74a902f4..512bb49a 100644 --- a/README.rdoc +++ b/README.rdoc @@ -33,7 +33,6 @@ These web servers include \Rack handlers in their distributions: * {NGINX Unit}[https://unit.nginx.org/] * {Phusion Passenger}[https://www.phusionpassenger.com/] (which is mod_rack for Apache and for nginx) * Puma[https://puma.io/] -* Unicorn[https://github.com/defunkt/unicorn] * uWSGI[https://uwsgi-docs.readthedocs.io/en/latest/] Any valid \Rack app will run the same on all these handlers, without -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/20191215040659.GA15403%40dcvr.
[-- Attachment #1.1: Type: text/plain, Size: 985 bytes --] On Thursday, May 23, 2019 at 9:42:06 AM UTC-7, raggi wrote: rackup is an opinionated tool that is good for 90% of use cases and adds > those middleware to meet that goal. > > I would say the behavior you need falls out of that use case set, and you > should consider writing your fastcgi spawner using the library primitives. > > Ah, yes, thanks. It'll probably end up that way; I'm just sketching it out right now: https://github.com/doriantaylor/rb-lazyauth Also the 'none' environment indeed seems to skip the stock middleware. Thanks! -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/fb1df7ca-7c07-4425-8336-099301549e59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 1645 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2303 bytes --] On Thu, May 23, 2019, 9:41 AM James Tucker <jftucker@gmail.com> wrote: > > > On Thu, May 23, 2019, 9:18 AM dorian taylor <dorian.taylor@gmail.com> > wrote: > >> >> >> On Thursday, May 23, 2019 at 9:15:24 AM UTC-7, raggi wrote: >>> >>> >>> Such a response is only valid in http 1.0, not http 1.1. >>> >>> In this regard rack won't help you much, as it isn't trying to provide >>> for that case. >>> >>> Have you considered not including this middleware for these requests? >>> >>> >> Do I get a choice in the matter? If I start the script with rackup it >> seems to add it all by itself: >> >> >> #<Rack::ContentLength:0x000055d0e32f7f60 >> @app= >> #<Rack::Chunked:0x000055d0e32f7fb0 >> @app= >> #<Rack::TempfileReaper:0x000055d0e2a07db0 >> @app=#<LazyAuth::App:0x000055d0e315e910>>>> >> #<LazyAuth::App:0x000055d0e315e910> >> >> >> > rackup is an opinionated tool that is good for 90% of use cases and adds > those middleware to meet that goal. > > I would say the behavior you need falls out of that use case set, and you > should consider writing your fastcgi spawner using the library primitives. > It's been a long while, but I think if you pass the "none" environment these middleware will be elided. > > > >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Rack Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rack-devel+unsubscribe@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rack-devel/7eb7b470-57d4-44dd-97fa-25bea17cce0f%40googlegroups.com >> <https://groups.google.com/d/msgid/rack-devel/7eb7b470-57d4-44dd-97fa-25bea17cce0f%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/CABGa_T82sGWikWx5H5oWS7%2BwxnFAU0%3Daiqczw9oFExmNEXuhaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 6907 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --] On Thu, May 23, 2019, 9:18 AM dorian taylor <dorian.taylor@gmail.com> wrote: > > > On Thursday, May 23, 2019 at 9:15:24 AM UTC-7, raggi wrote: >> >> >> Such a response is only valid in http 1.0, not http 1.1. >> >> In this regard rack won't help you much, as it isn't trying to provide >> for that case. >> >> Have you considered not including this middleware for these requests? >> >> > Do I get a choice in the matter? If I start the script with rackup it > seems to add it all by itself: > > > #<Rack::ContentLength:0x000055d0e32f7f60 > @app= > #<Rack::Chunked:0x000055d0e32f7fb0 > @app= > #<Rack::TempfileReaper:0x000055d0e2a07db0 > @app=#<LazyAuth::App:0x000055d0e315e910>>>> > #<LazyAuth::App:0x000055d0e315e910> > > > rackup is an opinionated tool that is good for 90% of use cases and adds those middleware to meet that goal. I would say the behavior you need falls out of that use case set, and you should consider writing your fastcgi spawner using the library primitives. > -- > > --- > You received this message because you are subscribed to the Google Groups > "Rack Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rack-devel+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rack-devel/7eb7b470-57d4-44dd-97fa-25bea17cce0f%40googlegroups.com > <https://groups.google.com/d/msgid/rack-devel/7eb7b470-57d4-44dd-97fa-25bea17cce0f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/CABGa_T_d1Z6FaJhewsbP2P6rbtKdAXE_nZFEUfStBYT4DQib4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 5568 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --] On Thursday, May 23, 2019 at 9:15:24 AM UTC-7, raggi wrote: > > > Such a response is only valid in http 1.0, not http 1.1. > > In this regard rack won't help you much, as it isn't trying to provide for > that case. > > Have you considered not including this middleware for these requests? > > Do I get a choice in the matter? If I start the script with rackup it seems to add it all by itself: #<Rack::ContentLength:0x000055d0e32f7f60 @app= #<Rack::Chunked:0x000055d0e32f7fb0 @app= #<Rack::TempfileReaper:0x000055d0e2a07db0 @app=#<LazyAuth::App:0x000055d0e315e910>>>> #<LazyAuth::App:0x000055d0e315e910> -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/7eb7b470-57d4-44dd-97fa-25bea17cce0f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 3272 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 731 bytes --] Never mind, looks like after rummaging through handler/fastcgi.rb, the answer is to set a Content-Length header to the empty string. This tricks Rack::Chunked which only tests for the presence of the header, not its content. I'm a bit apprehensive about this solution but for now it works. -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/3a971889-03c3-44b3-aade-d5cbe219e4e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 1089 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2248 bytes --] On Thu, May 23, 2019, 9:11 AM dorian taylor <dorian.taylor@gmail.com> wrote: > Hi, > > I'm trying to use Rack as a FastCGI authorizer (cf > https://github.com/fast-cgi/spec/blob/master/spec.md#63-authorizer ) in > conjunction with Apache mod_authnz_fcgi ( > https://httpd.apache.org/docs/2.4/mod/mod_authnz_fcgi.html ). My problem > is that mod_authnz_fcgi insists on a 200 status code and *only* a 200 > status code to communicate any results from the fastcgi script back up the > line. This is where Rack::Chunked is ruining my day: it forces the choice > of either a Content-Length header (which is transmitted upstream and > truncates the output), or a Transfer-Encoding: chunked header where the > accompanying *token* is removed upstream, resulting in a protocol error. > > I would like to be able to express an HTTP 200 response that has neither a > Content-Length nor a Transfer-Encoding header. Is there any way to disable > Rack::Chunked for certain responses? > Such a response is only valid in http 1.0, not http 1.1. In this regard rack won't help you much, as it isn't trying to provide for that case. Have you considered not including this middleware for these requests? -- > > --- > You received this message because you are subscribed to the Google Groups > "Rack Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rack-devel+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rack-devel/ab1058ab-ba08-4843-9489-86bcc55bde19%40googlegroups.com > <https://groups.google.com/d/msgid/rack-devel/ab1058ab-ba08-4843-9489-86bcc55bde19%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/CABGa_T_%2Be%3DnzMuyhe9%2BzKrab1mBeEEzw04F96%3DdTuv2Hxf_02w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 3799 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 1312 bytes --] Hi, I'm trying to use Rack as a FastCGI authorizer (cf https://github.com/fast-cgi/spec/blob/master/spec.md#63-authorizer ) in conjunction with Apache mod_authnz_fcgi (https://httpd.apache.org/docs/2.4/mod/mod_authnz_fcgi.html ). My problem is that mod_authnz_fcgi insists on a 200 status code and *only* a 200 status code to communicate any results from the fastcgi script back up the line. This is where Rack::Chunked is ruining my day: it forces the choice of either a Content-Length header (which is transmitted upstream and truncates the output), or a Transfer-Encoding: chunked header where the accompanying *token* is removed upstream, resulting in a protocol error. I would like to be able to express an HTTP 200 response that has neither a Content-Length nor a Transfer-Encoding header. Is there any way to disable Rack::Chunked for certain responses? -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rack-devel/ab1058ab-ba08-4843-9489-86bcc55bde19%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 1731 bytes --]
[-- Attachment #1: Type: text/plain, Size: 9822 bytes --] Vào 09:44:33 UTC+7 Thứ Tư, ngày 27 tháng 7 năm 2016, raggi đã viết: > Can you explain the cache hit rate assertions you open with? Sorry for evil post, mobile client. > > > > On Jul 26, 2016 7:10 PM, "Eric Wong" <e...@80x24.org> wrote: > This will improve cache hit rates and reduce caching overhead at > > small expense of increased header overhead for some user agents. > > For reference, Varnish cache supports only gzip as well: > > > > https://www.varnish-cache.org/docs/4.1/phk/gzip.html > > > > In the past, "deflate" encoding was more likely to trigger > > user-agent bugs, as noted in the comments removed with this > > change as well as the Varnish documentation referenced above. > > --- > > The following changes since commit 25a549883b85fb33970b4a1530a365c0c9e51f95: > > > > bumping to 2.0.1 to work around Rack (2016-06-30 10:33:09 -0700) > > > > are available in the git repository at: > > > > git://80x24.org/rack.git no-deflate > > > > for you to fetch changes up to d6380043a8953dca63743c947c8027f465d29a5d: > > > > deflater: remove "deflate" encoding support (2016-07-26 23:14:55 +0000) > > > > ---------------------------------------------------------------- > > Eric Wong (1): > > deflater: remove "deflate" encoding support > > > > lib/rack/deflater.rb | 37 +------------------------------------ > > test/spec_deflater.rb | 38 ++++++++++++++++++++++++-------------- > > 2 files changed, 25 insertions(+), 50 deletions(-) > > > > diff --git a/lib/rack/deflater.rb b/lib/rack/deflater.rb > > index 62a1124..79e39f5 100644 > > --- a/lib/rack/deflater.rb > > +++ b/lib/rack/deflater.rb > > @@ -8,7 +8,6 @@ module Rack > > # Currently supported compression algorithms: > > # > > # * gzip > > - # * deflate > > # * identity (no transformation) > > # > > # The middleware automatically detects when compression is supported > > @@ -41,7 +40,7 @@ module Rack > > > > request = Request.new(env) > > > > - encoding = Utils.select_best_encoding(%w(gzip deflate identity), > > + encoding = Utils.select_best_encoding(%w(gzip identity), > > request.accept_encoding) > > > > # Set the Vary HTTP header. > > @@ -57,10 +56,6 @@ module Rack > > mtime = headers.key?("Last-Modified") ? > > Time.httpdate(headers["Last-Modified"]) : Time.now > > [status, headers, GzipStream.new(body, mtime)] > > - when "deflate" > > - headers['Content-Encoding'] = "deflate" > > - headers.delete(CONTENT_LENGTH) > > - [status, headers, DeflateStream.new(body)] > > when "identity" > > [status, headers, body] > > when nil > > @@ -101,36 +96,6 @@ module Rack > > end > > end > > > > - class DeflateStream > > - DEFLATE_ARGS = [ > > - Zlib::DEFAULT_COMPRESSION, > > - # drop the zlib header which causes both Safari and IE to choke > > - -Zlib::MAX_WBITS, > > - Zlib::DEF_MEM_LEVEL, > > - Zlib::DEFAULT_STRATEGY > > - ] > > - > > - def initialize(body) > > - @body = body > > - @closed = false > > - end > > - > > - def each > > - deflator = ::Zlib::Deflate.new(*DEFLATE_ARGS) > > - @body.each { |part| yield deflator.deflate(part, Zlib::SYNC_FLUSH) } > > - yield fin = deflator.finish > > - ensure > > - deflator.finish unless fin > > - deflator.close > > - end > > - > > - def close > > - return if @closed > > - @closed = true > > - @body.close if @body.respond_to?(:close) > > - end > > - end > > - > > private > > > > def should_deflate?(env, status, headers, body) > > diff --git a/test/spec_deflater.rb b/test/spec_deflater.rb > > index ba7ec5d..0f27c85 100644 > > --- a/test/spec_deflater.rb > > +++ b/test/spec_deflater.rb > > @@ -81,13 +81,22 @@ describe Rack::Deflater do > > yield(status, headers, body) if block_given? > > end > > > > + # automatic gzip detection (streamable) > > + def auto_inflater > > + Zlib::Inflate.new(32 + Zlib::MAX_WBITS) > > + end > > + > > + def deflate_or_gzip > > + {'deflate, gzip' => 'gzip'} > > + end > > + > > it 'be able to deflate bodies that respond to each' do > > app_body = Object.new > > class << app_body; def each; yield('foo'); yield('bar'); end; end > > > > - verify(200, 'foobar', 'deflate', { 'app_body' => app_body }) do |status, headers, body| > > + verify(200, 'foobar', deflate_or_gzip, { 'app_body' => app_body }) do |status, headers, body| > > headers.must_equal({ > > - 'Content-Encoding' => 'deflate', > > + 'Content-Encoding' => 'gzip', > > 'Vary' => 'Accept-Encoding', > > 'Content-Type' => 'text/plain' > > }) > > @@ -98,15 +107,15 @@ describe Rack::Deflater do > > app_body = Object.new > > class << app_body; def each; yield('foo'); yield('bar'); end; end > > > > - verify(200, app_body, 'deflate', { 'skip_body_verify' => true }) do |status, headers, body| > > + verify(200, app_body, deflate_or_gzip, { 'skip_body_verify' => true }) do |status, headers, body| > > headers.must_equal({ > > - 'Content-Encoding' => 'deflate', > > + 'Content-Encoding' => 'gzip', > > 'Vary' => 'Accept-Encoding', > > 'Content-Type' => 'text/plain' > > }) > > > > buf = [] > > - inflater = Zlib::Inflate.new(-Zlib::MAX_WBITS) > > + inflater = auto_inflater > > body.each { |part| buf << inflater.inflate(part) } > > buf << inflater.finish > > > > @@ -118,32 +127,33 @@ describe Rack::Deflater do > > app_body = Object.new > > class << app_body; def each; yield('foo'); yield('bar'); end; end > > opts = { 'skip_body_verify' => true } > > - verify(200, app_body, 'deflate', opts) do |status, headers, body| > > + verify(200, app_body, 'gzip', opts) do |status, headers, body| > > headers.must_equal({ > > - 'Content-Encoding' => 'deflate', > > + 'Content-Encoding' => 'gzip', > > 'Vary' => 'Accept-Encoding', > > 'Content-Type' => 'text/plain' > > }) > > > > buf = [] > > - inflater = Zlib::Inflate.new(-Zlib::MAX_WBITS) > > + inflater = auto_inflater > > FakeDisconnect = Class.new(RuntimeError) > > assert_raises(FakeDisconnect, "not Zlib::DataError not raised") do > > body.each do |part| > > - buf << inflater.inflate(part) > > + tmp = inflater.inflate(part) > > + buf << tmp if tmp.bytesize > 0 > > raise FakeDisconnect > > end > > end > > - assert_raises(Zlib::BufError) { inflater.finish } > > + inflater.finish > > buf.must_equal(%w(foo)) > > end > > end > > > > # TODO: This is really just a special case of the above... > > it 'be able to deflate String bodies' do > > - verify(200, 'Hello world!', 'deflate') do |status, headers, body| > > + verify(200, 'Hello world!', deflate_or_gzip) do |status, headers, body| > > headers.must_equal({ > > - 'Content-Encoding' => 'deflate', > > + 'Content-Encoding' => 'gzip', > > 'Vary' => 'Accept-Encoding', > > 'Content-Type' => 'text/plain' > > }) > > @@ -280,7 +290,7 @@ describe Rack::Deflater do > > 'Content-Encoding' => 'identity' > > } > > } > > - verify(200, 'Hello World!', 'deflate', options) > > + verify(200, 'Hello World!', deflate_or_gzip, options) > > end > > > > it "deflate if content-type matches :include" do > > @@ -334,7 +344,7 @@ describe Rack::Deflater do > > :if => lambda { |env, status, headers, body| true } > > } > > } > > - verify(200, 'Hello World!', 'deflate', options) > > + verify(200, 'Hello World!', deflate_or_gzip, options) > > end > > > > it "not deflate if :if lambda evaluates to false" do > > -- > > EW > > > > -- > > > > --- > > You received this message because you are subscribed to the Google Groups "Rack Development" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to rack-...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --] Thank you Eric, applied in 9d25a133fa7651e60e23a46ef0b732fd131d3458. On Monday, March 11, 2019 at 8:26:58 PM UTC-4, Eric Wong wrote: > > Given the fragile design of yahns and the scary (but honest) > marketing of it; I've conceded it is unsuitable to mention in an > introductory document such as the rack README. > --- > README.rdoc | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/README.rdoc b/README.rdoc > index 83df7f42..883380c1 100644 > --- a/README.rdoc > +++ b/README.rdoc > @@ -37,7 +37,6 @@ These web servers include \Rack handlers in their > distributions: > * Reel > * unixrack > * uWSGI > -* yahns > > Any valid \Rack app will run the same on all these handlers, without > changing anything. > -- > EW > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 1458 bytes --]
Given the fragile design of yahns and the scary (but honest) marketing of it; I've conceded it is unsuitable to mention in an introductory document such as the rack README. --- README.rdoc | 1 - 1 file changed, 1 deletion(-) diff --git a/README.rdoc b/README.rdoc index 83df7f42..883380c1 100644 --- a/README.rdoc +++ b/README.rdoc @@ -37,7 +37,6 @@ These web servers include \Rack handlers in their distributions: * Reel * unixrack * uWSGI -* yahns Any valid \Rack app will run the same on all these handlers, without changing anything. -- EW -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[-- Attachment #1: Type: text/plain, Size: 580 bytes --] On Thu, Jan 03, 2019 at 11:10:31PM +0000, Eric Wong wrote: > unicorn is already well-known, so referencing it here is > unnecessary clutter. By removing it from this list, we can give > other servers more exposure. Applied. Thanks! -- Aaron Patterson http://tenderlovemaking.com/ -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
unicorn is already well-known, so referencing it here is unnecessary clutter. By removing it from this list, we can give other servers more exposure. Besides, the robustness of unicorn has unfortunately led to unfixed bugs in other parts of the Rack ecosystem. --- Fwiw, I'm happy to continue maintaining unicorn indefinitely as long as people need and use it. But I've never cared for promoting it and never will. README.rdoc | 1 - 1 file changed, 1 deletion(-) diff --git a/README.rdoc b/README.rdoc index 98780322..170d8f32 100644 --- a/README.rdoc +++ b/README.rdoc @@ -36,7 +36,6 @@ These web servers include \Rack handlers in their distributions: * Phusion Passenger (which is mod_rack for Apache and for nginx) * Puma * Reel -* Unicorn * unixrack * uWSGI * yahns -- EW -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[-- Attachment #1.1: Type: text/plain, Size: 1697 bytes --] Hi there, I am one of the maintainers of [Moneta][1]. Until a couple of days ago we were still testing against a rather ancient set of MRI Ruby versions, but we have just decided we need to modernise, and as part of that the question of what sort of policy we should have concerning the minimum supported Ruby version (i.e. `required_ruby_version` in the gemspec) has arisen. Because Moneta is designed for use with web projects that mostly depend on Rack, we thought we would follow Rack's lead on this, so that anyone who is able to use Rack can also use Moneta. This has of course lead us to wondering what the Rack team's policy on this is. Do you think it makes sense to phase out MRI rubies once they have EOLed, or do you think there is virtue in maintaining support for older versions beyond that? As Ruby 2.2 will be EOLed at the end of this week, we are keen to know if you think there is merit in maintaining 2.2 support beyond that time. Also, my own understanding of how gem semver should fit with minimum Ruby versions is not that clear. I see that Rack introduced the `>= 2.2.0` requirement with v2 of the gem, so do you think that changing the minimum Ruby from say, 2.2 to 2.3 should only be done as part of a major version change of the gem? I'm very keen to hear your thoughts on any or all of the above. Thanks in advance! -Alastair [1]: https://github.com/minad/moneta -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 2091 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 3044 bytes --] Thank you Eric. This patch was applied at 2e92a25342b5d51f4094366c3b8dd797cbd208a4. On Friday, December 29, 2017 at 1:34:30 AM UTC-5, Eric Wong wrote: > > Using the Queue class in stdlib is sufficient for this test, > so there's no need for a new development dependency. > > And one big reason I like webrick is it's bundled with > Ruby and has no 3rd-party C ext dependencies; so having > to download and install one is a bummer. > --- > If you prefer to use "git pull": > > The following changes since commit > ab008307cbb805585449145966989d5274fbe1e4: > > Add test to make sure `Rack::Builder#call` always create a new app > (2017-11-06 23:27:12 -0500) > > are available in the Git repository at: > > git://80x24.org/rack.git webrick-devdep > > for you to fetch changes up to 64349662ac18f52849cc215494d77e3719dfa2a7: > > webrick: remove concurrent-ruby dev dependency (2017-12-29 06:25:29 > +0000) > > ---------------------------------------------------------------- > Eric Wong (1): > webrick: remove concurrent-ruby dev dependency > > rack.gemspec | 1 - > test/spec_webrick.rb | 11 +++++------ > 2 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/rack.gemspec b/rack.gemspec > index ec2b79f6..d8374287 100644 > --- a/rack.gemspec > +++ b/rack.gemspec > @@ -30,6 +30,5 @@ EOF > > s.add_development_dependency 'minitest', "~> 5.0" > s.add_development_dependency 'minitest-sprint' > - s.add_development_dependency 'concurrent-ruby' > s.add_development_dependency 'rake' > end > diff --git a/test/spec_webrick.rb b/test/spec_webrick.rb > index e3050f6f..855fa9eb 100644 > --- a/test/spec_webrick.rb > +++ b/test/spec_webrick.rb > @@ -1,6 +1,6 @@ > require 'minitest/autorun' > require 'rack/mock' > -require 'concurrent/atomic/event' > +require 'thread' > require File.expand_path('../testrequest', __FILE__) > > Thread.abort_on_exception = true > @@ -119,7 +119,7 @@ describe Rack::Handler::WEBrick do > end > > it "provide a .run" do > - latch = Concurrent::Event.new > + queue = Queue.new > > t = Thread.new do > Rack::Handler::WEBrick.run(lambda {}, > @@ -129,13 +129,12 @@ describe Rack::Handler::WEBrick do > :Logger => WEBrick::Log.new(nil, > WEBrick::BasicLog::WARN), > :AccessLog => []}) { |server| > assert_kind_of WEBrick::HTTPServer, server > - @s = server > - latch.set > + queue.push(server) > } > end > > - latch.wait > - @s.shutdown > + server = queue.pop > + server.shutdown > t.join > end > > -- > EW > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 4415 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3177 bytes --] +1 On Dec 28, 2017 10:34 PM, "Eric Wong" <e@80x24.org> wrote: > Using the Queue class in stdlib is sufficient for this test, > so there's no need for a new development dependency. > > And one big reason I like webrick is it's bundled with > Ruby and has no 3rd-party C ext dependencies; so having > to download and install one is a bummer. > --- > If you prefer to use "git pull": > > The following changes since commit ab008307cbb805585449145966989d > 5274fbe1e4: > > Add test to make sure `Rack::Builder#call` always create a new app > (2017-11-06 23:27:12 -0500) > > are available in the Git repository at: > > git://80x24.org/rack.git webrick-devdep > > for you to fetch changes up to 64349662ac18f52849cc215494d77e3719dfa2a7: > > webrick: remove concurrent-ruby dev dependency (2017-12-29 06:25:29 > +0000) > > ---------------------------------------------------------------- > Eric Wong (1): > webrick: remove concurrent-ruby dev dependency > > rack.gemspec | 1 - > test/spec_webrick.rb | 11 +++++------ > 2 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/rack.gemspec b/rack.gemspec > index ec2b79f6..d8374287 100644 > --- a/rack.gemspec > +++ b/rack.gemspec > @@ -30,6 +30,5 @@ EOF > > s.add_development_dependency 'minitest', "~> 5.0" > s.add_development_dependency 'minitest-sprint' > - s.add_development_dependency 'concurrent-ruby' > s.add_development_dependency 'rake' > end > diff --git a/test/spec_webrick.rb b/test/spec_webrick.rb > index e3050f6f..855fa9eb 100644 > --- a/test/spec_webrick.rb > +++ b/test/spec_webrick.rb > @@ -1,6 +1,6 @@ > require 'minitest/autorun' > require 'rack/mock' > -require 'concurrent/atomic/event' > +require 'thread' > require File.expand_path('../testrequest', __FILE__) > > Thread.abort_on_exception = true > @@ -119,7 +119,7 @@ describe Rack::Handler::WEBrick do > end > > it "provide a .run" do > - latch = Concurrent::Event.new > + queue = Queue.new > > t = Thread.new do > Rack::Handler::WEBrick.run(lambda {}, > @@ -129,13 +129,12 @@ describe Rack::Handler::WEBrick do > :Logger => WEBrick::Log.new(nil, > WEBrick::BasicLog::WARN), > :AccessLog => []}) { |server| > assert_kind_of WEBrick::HTTPServer, server > - @s = server > - latch.set > + queue.push(server) > } > end > > - latch.wait > - @s.shutdown > + server = queue.pop > + server.shutdown > t.join > end > > -- > EW > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Rack Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rack-devel+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 4403 bytes --]
Using the Queue class in stdlib is sufficient for this test, so there's no need for a new development dependency. And one big reason I like webrick is it's bundled with Ruby and has no 3rd-party C ext dependencies; so having to download and install one is a bummer. --- If you prefer to use "git pull": The following changes since commit ab008307cbb805585449145966989d5274fbe1e4: Add test to make sure `Rack::Builder#call` always create a new app (2017-11-06 23:27:12 -0500) are available in the Git repository at: git://80x24.org/rack.git webrick-devdep for you to fetch changes up to 64349662ac18f52849cc215494d77e3719dfa2a7: webrick: remove concurrent-ruby dev dependency (2017-12-29 06:25:29 +0000) ---------------------------------------------------------------- Eric Wong (1): webrick: remove concurrent-ruby dev dependency rack.gemspec | 1 - test/spec_webrick.rb | 11 +++++------ 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/rack.gemspec b/rack.gemspec index ec2b79f6..d8374287 100644 --- a/rack.gemspec +++ b/rack.gemspec @@ -30,6 +30,5 @@ EOF s.add_development_dependency 'minitest', "~> 5.0" s.add_development_dependency 'minitest-sprint' - s.add_development_dependency 'concurrent-ruby' s.add_development_dependency 'rake' end diff --git a/test/spec_webrick.rb b/test/spec_webrick.rb index e3050f6f..855fa9eb 100644 --- a/test/spec_webrick.rb +++ b/test/spec_webrick.rb @@ -1,6 +1,6 @@ require 'minitest/autorun' require 'rack/mock' -require 'concurrent/atomic/event' +require 'thread' require File.expand_path('../testrequest', __FILE__) Thread.abort_on_exception = true @@ -119,7 +119,7 @@ describe Rack::Handler::WEBrick do end it "provide a .run" do - latch = Concurrent::Event.new + queue = Queue.new t = Thread.new do Rack::Handler::WEBrick.run(lambda {}, @@ -129,13 +129,12 @@ describe Rack::Handler::WEBrick do :Logger => WEBrick::Log.new(nil, WEBrick::BasicLog::WARN), :AccessLog => []}) { |server| assert_kind_of WEBrick::HTTPServer, server - @s = server - latch.set + queue.push(server) } end - latch.wait - @s.shutdown + server = queue.pop + server.shutdown t.join end -- EW -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.