roda 3.82.0 → 3.84.0

data/doc/release_notes/3.16.0.txt

@@ -1,52 +0,0 @@
-= New Features
-
-* A mail_processor plugin has been added for processing mail using
-  a routing tree. Quick example:
- 
-    class MailProcessor < Roda
-      plugin :mail_processor
- 
-      route do |r|
-        # Match based on the To header, extracting the ticket_id
-        r.to /ticket\+(\d+)@example.com/ do |ticket_id|
-          if ticket = Ticket[ticket_id.to_i]
-            # Mark the mail as handled if there is a valid ticket
-            # associated
-            r.handle do
-              ticket.add_note(text: mail_text, from: from)
-            end
-          end
-        end
-      end
-    end
-
-  You can submit mail for processing by calling the process_mail
-  method with a Mail instance:
-
-    MailProcessor.process_mail(Mail.read('/path/to/message.eml'))
-
-  The mail_processor routing tree uses routing methods specific to
-  mail:
- 
-  r.from :: match on the mail From address
-  r.to :: match on the mail To address
-  r.cc :: match on the mail CC address
-  r.rcpt :: match on the mail recipients (To and CC addresses by
-            default)
-  r.subject :: match on the mail subject
-  r.body :: match on the mail body
-  r.text :: match on text extracted from the message (same as mail
-            body by default)
-  r.header :: match on a mail header
-
-  To mark a mail as having been handled, you call the r.handle method
-  with a block, or one of the above methods prefixed by handle_
-  (e.g. r.handle_text).
-
-  The mail_processor plugin supports hooks that are called for handled
-  mail, unhandled mail, and all mail (for archiving).  It also
-  supports the ability to configure how reply text is parsed out of
-  mail, who to consider as the recipients of the email, and the
-  ability to have separate routing blocks per recipient email address
-  (with O(1) delegation to the appropriate block if the recipient
-  addresses to match is a string).

data/doc/release_notes/3.17.0.txt

@@ -1,62 +0,0 @@
-= New Features
-
-* A route_block_args plugin has been added, allowing you to customize
-  which objects are yielded to the the route block. You call the
-  plugin with a block, which is evaluated in the context of the
-  instance and should return an array of arguments for the instance
-  to yield to the route block.
-  
-  To yield both the request and response objects, you can do:
-
-    plugin :route_block_args do |r|
-      [r, response]
-    end
-
-    route do |r, response|
-      # ...
-    end
-
-  In addition to the main route block, using this plugin also affects
-  the arguments passed to routing blocks in the following plugins:
-
-  * class_level_routing
-  * mailer
-  * mail_processor
-  * multi_route
-  * static_routing
-
-= Other Improvements
-
-* The set_layout_opts method in the view_options plugin can now
-  override the layout template even if the render plugin :layout
-  option is given.
-
-* The mailer and mail_processor plugin now integrate with the hooks
-  plugin to support before/after hooks.
-
-* Dispatching to the route block and RodaResponse#finish are both
-  slightly faster.
-
-* Internal before hook handling has been moved from an internal
-  plugin into the core, and modified so that if you are not using
-  the internal before hook in any plugin, there is no runtime cost.
-
-* The core now recognizes when plugins are using the internal after
-  hook, and automatically loads the internal plugin supporting the
-  after hook.
-
-= Backwards Compatibility
-
-* When using the render plugin with a :layout option, the render_opts
-  :layout option will be set to true if the layout is enabled.
-  Previously, the render_opts :layout option would retain the value
-  given as the plugin option.  Options for the layout (including the
-  template) are still available in the render_opts :layout_opts
-  option.  This change was made to fix the set_layout_opts bug in the
-  view_options plugin.
-
-* RodaResponse#initialize no longer sets the response status to nil
-  if it was already set.
-
-* RodaResponse#finish no longer sets the status on the receiver, it
-  just uses the receiver's status to set the rack response status.

data/doc/release_notes/3.18.0.txt

@@ -1,170 +0,0 @@
-= New Features
-
-* A direct_call plugin has been added.  This plugin makes Roda.call
-  call the app directly, skipping any middleware.  This plugin
-  can be used for performance reasons, as the class itself can be
-  used as the base rack app, instead of using a lambda as the base
-  rack app.  Roda.app.call will still call all middleware when
-  using this plugin.
-
-= Other Improvements
-
-* Blocks that are given during application configuration, and
-  previously executed with instance_exec, instead now define methods,
-  and Roda now calls these methods. This is a much faster approach.
-  This new approach, combined with the direct_call plugin and the
-  Roda.freeze optimizations, can be over 80% faster for trivial
-  applications, with measureable improvements in most applications.
-
-  As methods are strict in regards to arity and instance_exec is
-  not, Roda now checks all such blocks for arity mismatches, and
-  attempts to compensate for arity mismatches.  In case of an arity
-  mismatch, Roda will define a method that will call instance_exec,
-  in which case there will not be a performance improvement.
-
-  For some methods, Roda may not know the expected arity until
-  runtime.  In that case, Roda will check the arity at runtime and
-  try to call the method with the arity that it supports if there is
-  an arity mismatch.
-
-  You can control the checking of arity via two options:
-
-  :check_arity :: Set to false to turn off all arity checking. Set to
-                  :warn to issue a warning when defining the method if
-                  there is an arity mismatch (for methods where the
-                  expected arity is known in advance).
-  :check_dynamic_arity :: Set to false to turn off arity checking for
-                          methods defined where the arity is not known
-                          at compile time.  Set to :warn to issue a
-                          warning at runtime every time the method is
-                          called and there is an arity mismatch (for
-                          methods where the expected arity is not
-                          known in advance).  Note that checking the
-                          arity at runtime has a performance cost,
-                          so for maximum performance this should be
-                          set to false.
-
-  Note that this arity checking is only done to keep backwards
-  compatibility.  Since lambdas already used strict arity, no arity
-  checking is done if the block is a lambda and not a regular proc.
-
-  Roda has a new dispatch API that works with these defined methods.
-  The new dispatch API uses the following methods:
-
-  * _roda_handle_main_route: Entry point for normal request dispatch.
-  * _roda_handle_route: Yields to the routing block, catching any
-    halts inside the block, treating the block as a routing block.
-  * _roda_main_route: Roda.route defines this method using the
-    block provided, it accepts the request as an argument.
-  * _roda_run_main_route: Calls _roda_main_route with the request,
-    allowing for plugins to execute code around the main routing,
-    while still being able to throw :halt to return a response.
-
-  All instance methods defined by Roda use the _roda_ prefix.
-
-* When deleting the session cookie in the sessions plugin, the
-  Set-Cookie response header now uses the same path and domain 
-  that was originally used to set the cookie.  This can fix cases
-  where the cookie was not being cleared as expected.
-
-* Freezing a Roda app now can add performance improvements in
-  addition to reliability improvements. When freezing the class,
-  if certain methods in the class have not been overridden, Roda
-  now defines aliases or more optimized methods to improve
-  performance.
-
-* Roda now warns if the Roda#call method is overridden in a module,
-  without the module also overridding _roda_handle_main_route or
-  _roda_run_main_route.  This indicates that the module needs
-  to be updated to use Roda's new dispatch API.  Roda will continue
-  to work in this case, but it will be slower than the Roda's now
-  default behavior, as it will force usage of the old dispatch API.
-  This check will be removed in Roda 4, which will remove support
-  for Roda#call (and Roda#_call).
-
-* When there is only a single internal before or after hook defined,
-  the hook is now faster by using a method alias.
-
-* The route_csrf plugin block or :csrf_failure option proc now
-  integrates with the route_block_args plugin.
-
-* The default_status plugin is now faster by defining the
-  default_status method directly.
-
-* The default_headers plugin is now faster by defining an optimized
-  set_default_headers method directly.
-
-* The hooks plugin is now faster by defining methods for each
-  hook block, with a main hook method that dispatches to each
-  of the hook block methods.  If only a single hook block is
-  used, the main hook method is an alias to the hook block
-  method to avoid an extra method call.
-
-* The following plugins now use define_method instead of
-  instance_exec for better performance:
-
-  * defaults_setter
-  * mail_processor
-  * multi_route
-  * named_templates
-  * path
-  * route_block_args
-  * route_csrf
-  * static_routing
-  * status_handler
-
-* The internal after hook implementation has now been merged into
-  the error_handler plugin. This is faster in cases where the
-  error_handler plugin is used, and slower in cases where the
-  internal after hook plugin was used without the error_handler
-  plugin.
-
-* The route_block_args plugin now handles cases where
-  Roda.convert_route_block has already been overridden.
-
-* Performance of routing methods that can yield captures has been
-  improved.
-
-* Hash#merge is now used in preference to Hash[].merge! in cases
-  where the receiver of Hash#merge would not be provided by the
-  user.  This is because Hash#merge is faster than Hash[].merge!
-  in recent ruby versions.  If the receiver of #merge is provided
-  by the user, then Hash[].merge! is still used to ensure that the
-  resulting value is plain hash.
-
-* The static_routing plugin no longer removes existing static
-  routes if loaded more than once.
-
-* Roda now warns when calling Roda.route without a block.
-
-= Backwards Compatibility
-
-* The route_block_args plugin no longer affects the
-  class_level_routing plugin.  Support for this was added in Roda
-  3.17.0 when the route_block_args plugin was added, but this was a
-  mistake as class_level_routing blocks should be called with the
-  captures for their matchers, not with the route block args.
-
-* Some of the internal state was changed in the following plugins:
-
-  * class_level_routing
-  * mail_processor
-  * multi_route
-  * named_templates
-  * static_routing
-  * status_handler
-
-  This only affects you if you were accessing the internal state
-  via the opts hash.
-
-* The static_routing plugin no longer defines the r.static_route
-  method.
-
-* The mailer plugin was switched to use the new dispatch API, and
-  will no longer handle cases where the old dispatch API (Roda#call)
-  was overrridden.
-
-* The static_route method in the static_routing plugin must
-  now be called with a block.  Previously, that would not
-  cause a failure until runtime, where it would fail when
-  you tried to execute the route.

data/doc/release_notes/3.19.0.txt

@@ -1,229 +0,0 @@
-= New Features
-
-* A hash_routes plugin has been added for O(1) route dispatching at
-  any level of the routing tree.  By default, Roda uses a linear
-  search of possible branches at each level of the routing tree,
-  which results in roughly O(log(n)) routing behavior in most
-  applications (where n is the total number of routes in the
-  application).
-  
-  Assume you have the following routing tree:
-
-    route do |r|
-      r.on "a" do
-        # ...
-      end
-
-      r.on "b" do
-        # ...
-      end
-
-      r.is "c" do
-        # ...
-      end
-
-      # ...
-    end
-
-  With this routing tree, a request for /c will first check /a and
-  /b.  This is not normally a performance issue, but if you have a
-  large number of routes at a particular level, it can be.
-
-  The hash_routes plugin allows you to convert this routing tree to:
-
-    plugin :hash_routes
-
-    hash_routes do
-      on "a" do |r|
-        # ...
-      end
-
-      on "b" do |r|
-        # ...
-      end
-
-      is "c" do |r|
-        # ...
-      end
-
-      # ...
-    end
-
-    route do |r|
-      r.hash_routes
-    end
-
-  This routing tree looks similar to Roda's standard routing tree, and
-  will have the same behavior as the previous example, but dispatching
-  to the routes inside the hash_routes block by the r.hash_routes
-  method will be an O(1) operation, instead of a linear search.  This
-  can significantly improve performance in cases where you have a large
-  number of branches at any point in the routing tree.
-
-  In order to support O(1) route dispatching at any level of the
-  tree, the hash_routes plugin supports namespaces.  You can use this
-  namespace support to keep the primary advantage of Roda when using
-  the hash_routes plugin, which is the ability to operate on a request
-  at any point during routing.  Assume you have this routing tree:
-
-    hash_routes :root do
-      on "foo" do |r|
-        r.on Integer do |foo_id|
-          next unless @foo = Foo[foo_id]
-          r.hash_routes(:foo)
-        end
-      end
-
-      on "bar" do |r|
-        r.on Integer do |bar_id|
-          next unless @bar = Bar[bar_id]
-          r.hash_routes(:bar)
-        end
-      end
-
-      # ...
-    end
-
-    hash_routes :foo do
-      get "show" do
-        @page_title = @foo.name
-        view('foo/show')
-      end
-
-      # ...
-    end
-
-    hash_routes :bar do
-      post "edit" do
-        @bar.update(:name=>request.params['name'])
-        r.redirect "/"
-      end
-
-      # ...
-    end
-
-    route do |r|
-      r.hash_routes(:root)
-    end
-
-  With this routing tree, a GET /foo/123/show request will first get
-  dispatched to the on "foo" block in the :root namespace.  That will
-  extract the 123 segment from the path, and use it to find the Foo
-  object with id 123 and set that to the instance variable @foo.
-  If there is no matching foo, the rest of the block will be skipped,
-  which will result in a 404 response.  If there is a matching foo,
-  after setting the instance variable, it will dispatch to routes in
-  the :foo namespace, one of which is show, which will be able to use
-  the @foo variable, both in the route and in the view.
-  
-  Similarly, a POST /bar/321/edit request would dispatch to the on
-  "bar" block in the :root namespace, will look up the matching bar,
-  then will dispatch to the edit route in the :bar namespace.
-
-  The hash_routes plugin can be used as a faster version of the
-  multi_route plugin's r.multi_route method.  It can also be used as
-  a faster replacement for the multi_view plugin.
-  
-  Please see the hash_routes plugin documentation for additional
-  methods and configuration styles supported by the plugin.
-
-* A match_hook plugin has been added, which is called for each
-  successful match, before yielding to the match block.  For example,
-  with the following routing tree:
-
-    plugin :match_hook
-
-    match_hook do
-      puts "#{r.matched_path}|#{r.remaining_path}"
-    end
-
-    route do |r|
-      r.on "a" do
-        r.is "b" do
-          r.get do
-          end
-
-          r.post do
-          end
-        end
-      end
-    end
-
-  A GET request for /a/b would call the match hook three times, and
-  output the following:
-
-    /a|/b # When the r.on block matches
-    /a/b| # When the r.is block matches
-    /a/b| # When the r.get block matches
-
-  A GET request for /a/c would call the match hook once, and output
-  the following:
-
-    /a|/b # When the r.on block matches
-
-  This plugin can be used to make debugging easier, as well as for
-  metrics.
-
-= Other Improvements
-
-* Per-cookie cipher secrets are now supported and used automatically
-  by default in the sessions plugin.  This can prevent issues where
-  the cipher secret can be leaked if the random initialization vector
-  turns out not to be so random and ends up being reused.  This
-  makes the session cookies slightly larger and about 10-20% slower.
-
-  Note that because of the way the sessions plugin is designed,
-  even if the cipher secret was leaked and you are not using
-  per-cookie cipher secrets, it would not allow an attacker to
-  forge a session, it would only allow them to read the contents of
-  an existing session.
-
-  If you are currently using the sessions plugin, and performing
-  rolling restarts, you should temporarily disable per-cookie session
-  secrets until all processes have been restarted and are able to
-  support per-cookie session secrets.  You can do so by setting the
-  :per_cookie_cipher_secret sessions plugin option to false
-  temporarily until all processes have restarted and are running Roda
-  3.19.0+.
-
-* When passing route blocks to Roda that have 0 arity instead of the
-  expected arity of 1, emulate an arity of 1 using an approach that is
-  about 2.75-8x faster.  This emulation is still about 20% slower than
-  using the expected arity.
-
-* Fix emulation of route blocks that have >1 arity but where the
-  expected arity is 1.  Such blocks were not handled correctly in
-  Roda 3.18.0.
-
-* String matching performance has been improved by 10-20%.
-
-* Symbol and String class matching performance has improved by 10-20%.
-
-* Terminal matching performance has improved by about 4x.
-
-* Roda will now automatically load the direct_call plugin when
-  freezing the application if there is no middleware used and the
-  application has not been subclassed, for improved performance.
-
-* Roda no longer builds the rack application until the app class
-  method is called.  This can fix O(n^2) issues when building
-  applications with a lot of middleware.  One consequence of
-  this is that a Roda.route block is no longer required. If
-  Roda.route is not called, then the default routing tree will
-  return a 404 response for all requests.
-
-  The delay_build plugin used to support delaying building the rack
-  application until a build! method is called.  Now that Roda delays
-  building the rack application until the app method is called, there
-  is no reason to use this plugin, and it is now a no-op.
-
-* The assets plugin :timestamp_paths option now supports a string
-  value to use a custom separator. A slash separator is still used
-  by default.
-
-= Backwards Compatibility
-
-* The static_routing plugin internals have changed, as the
-  static_routing is now implemented via the hash_routes plugin.  If
-  you were depending on the internals, you will need to update your
-  code.

data/doc/release_notes/3.2.0.txt

@@ -1,22 +0,0 @@
-= New Features
-
-* A timestamp_public plugin has been added for serving static files
-  with paths that change based on the modification timestamp of the
-  file.  By using a new path, cached versions of the file will not
-  be used, fixing staleness issues.  Example:
-
-    plugin :timestamp_public
-
-    route do |r|
-      # serves requests for /static/\d+/.*
-      r.timestamp_public
-
-      # /static/1234567890/path/to/file
-      timestamp_path("path/to/file")
-    end
-
-= Other Improvements
-
-* When using the assets plugin :timestamp_paths option, the
-  timestamps now include microseconds, to make cache poisoning more
-  difficult.

data/doc/release_notes/3.20.0.txt

@@ -1,7 +0,0 @@
-= Improvements
-
-* For empty responses with status code 205, a Content-Length header
-  is now added with a value of 0, for better conformance to RFC 7232.
-
-  Similarly, when using the drop_body plugin, responses with status
-  code 205 now have a Content-Length header added with a value of 0.

data/doc/release_notes/3.21.0.txt

@@ -1,5 +0,0 @@
-= Improvements
-
-* View rendering speed is significantly improved in development mode
-  by caching file-based templates until there has been a modification
-  to the template file.

data/doc/release_notes/3.22.0.txt

@@ -1,24 +0,0 @@
-= Improvements
-
-* The render/view methods in the render plugin, when called with
-  a single string/symbol argument (the most common case), are now
-  up to 2.5x/4x faster by directly calling compiled template methods.
-  This works by extracting the UnboundMethod objects that Tilt
-  creates, and defining real methods for them, then calling those
-  methods using send. This avoids most of the overhead of the render
-  and view methods.  The compiled template methods are defined inside
-  a module included in the Roda app's class, so this support works
-  even if the Roda app itself is frozen.
-
-  Some plugins, such as render_locals, do not work with this
-  optimization, and disable the use of it.  The view_options plugin
-  does work with this optimization if you are using set_view_subdir or
-  append_view_subdir, but not if using set_view_options or
-  set_layout_options.
-
-  This optimization depends on Ruby 2.3+ and Tilt 1.2+, and will not
-  be used on earlier versions, or if an API change in Tilt is
-  detected.
-
-* Session deserialization is now slightly faster in the sessions
-  plugin.

data/doc/release_notes/3.23.0.txt

@@ -1,28 +0,0 @@
-= Improvements
-
-* The render/view methods in the render plugin, when called with
-  a single string/symbol argument (the most common case), are now
-  up to 2x faster in cache: false mode by directly calling compiled
-  template methods.  This takes the performance increase in 3.22.0
-  and applies it to cache: false mode in addition to cache: true
-  mode.  If the template file has changed, the compiled method is
-  removed, and a new compiled method replaces it.
-
-* Template modification detection in the render plugin now uses a
-  faster check for modification, which also avoids a race condition.
-
-* The type_routing plugin now handles requests with nothing but the
-  extension in the request path.  This fixes cases when you have
-  one app partially route a request, and send the request to another
-  app, and that app uses the type_routing plugin and has an r.is
-  call at the root level.
-
-* The roda/session_middleware middleware now works correctly if the
-  type_routing plugin is loaded into Roda itself (as opposed to a
-  Roda subclass).
-
-* The exception_page plugin now always shows the line number for
-  each line.  Previously, it only showed the line number if it was
-  showing the content of the line, which complicated debugging in
-  cases where the content of the line was no longer retrievable
-  due to file system permissions or restrictions (e.g. chroot).

data/doc/release_notes/3.24.0.txt

@@ -1,14 +0,0 @@
-= Improvements
-
-* The performance of the render_each plugin has been dramatically
-  improved by calling compiled template methods directly. For a simple
-  template, render_each performance with a single object can be about
-  2x faster, and render_each performance for 100 objects can be 3x
-  (cache: false) to 9x (cache: true) faster.
-
-  This optimization can be used if no options are provided to
-  render_each, or if :local and/or :locals options are provided. Use
-  of other options will disable this optimization.
-
-* The module_include plugin no longer calls Proc.new without a
-  block, fixing a warning on Ruby 2.7.

data/doc/release_notes/3.25.0.txt

@@ -1,12 +0,0 @@
-= Improvements
-
-* The new tilt 2.0.10 private API is now supported when using
-  compiled template methods, with up to a 33% performance increase.
-  The older tilt private API (back to tilt 1.2) is still supported.
-
-* The performance of the render and view methods in the render plugin
-  when called with only the :locals option are now about 75% faster
-  by calling compiled template methods directly.
-
-* Keyword argument separation issues are now handled on Ruby 2.7+
-  when defining methods with blocks that accept keyword arguments.

data/doc/release_notes/3.26.0.txt

@@ -1,15 +0,0 @@
-= New Features
-
-* Asynchronous streaming is now supported in the streaming plugin,
-  using the :async option.  When using this option, streaming
-  responses are temporarily buffered in a queue.  By default, the
-  queue is a sized queue with a maximum of 10 elements, but the
-  queue can be specified manually via the :queue option, which
-  can be used with async libraries that support non-blocking
-  queues.  This option is currently only supported on Ruby 2.3+.
-
-= Other Improvements
-
-* When combining multiple compiled assets into a single file, the
-  files are now separated by a newline, fixing issues when a
-  single line comment is used as the last line of a file.

data/doc/release_notes/3.27.0.txt

@@ -1,15 +0,0 @@
-= New Features
-
-* A multibyte_string_matcher plugin has been added that supports
-  multibyte characters in strings used as matchers.  It uses a slower
-  string matching implementation that supports multibyte characters.
-  As multibyte strings in paths must be escaped, this also loads the
-  unescape_path plugin.
-
-= Other Improvements
-
-* The json_parser plugin now returns expected results for invalid JSON
-  if the params_capturing plugin is used.
-
-* lib/roda.rb has been split into multiple files for easier code
-  navigation.

data/doc/release_notes/3.28.0.txt

@@ -1,13 +0,0 @@
-= New Features
-
-* The sessions plugin now supports RodaRequest#session_created_at
-  and RodaRequest#session_updated_at for the times of session
-  creation and last update.
-
-= Other Improvements
-
-* The json_parser plugin now correctly parses the request body even
-  if the request body has already been read.
-
-* The sessions plugin now correctly handles upgrading rack cookie
-  sessions when using rack 2.0.8+.