Permalink
Commits on May 29, 2016
  1. update dependencies

    igrigorik committed May 29, 2016
    Ruby <2.1 is deprecated.
Commits on Feb 12, 2016
  1. Merge pull request #323 from boazsegev/patch-1

    igrigorik committed Feb 12, 2016
    Conform to the `QUERY_STRING` Rack requirements (not `nil`)
Commits on Feb 11, 2016
  1. Make sure that `QUERY_STRING` isn't `nil`

    boazsegev committed Feb 11, 2016
    According to [the Rack specs](http://www.rubydoc.info/github/rack/rack/file/SPEC), `QUERY_STRING` must be present, even if empty.
    
    > The portion of the request URL that follows the ?, if any. May be empty, **but is always required!**
    
    The URI parser will return `nil` for a missing `QUERY_STRING`, which results in non-conformity with the Rack standard.
    
    By making sure this is a string, this issue would be resolved.
Commits on Jun 26, 2015
  1. Merge pull request #316 from ajvondrak/prevent-params-from-swallowing…

    dj2 committed Jun 26, 2015
    …-errors
    
    Prevent Goliath::Rack::Params from swallowing downstream errors
Commits on Jun 6, 2015
  1. Prevent Goliath::Rack::Params from swallowing downstream errors

    ajvondrak committed Jun 6, 2015
    I ran into this behavior when I wanted to add an error tracking service to my
    Goliath application (for me, [Airbrake](https://airbrake.io/), but the specific
    service is tangential). To implement this, I added a middleware at the very top
    of the chain that delegated downstream while rescuing any exceptions. Roughly:
    
    ```ruby
    class ExceptionHandlingMiddleware
      include Goliath::Rack::AsyncMiddleware
    
      def call(env)
        super
      rescue Exception => e
        # track the exception, do some cleanup, return a generic response, etc.
      end
    end
    ```
    
    When I added this middleware to my API, though, it wasn't working. After enough
    experimentation, I discovered that it had to do with my use of
    Goliath::Rack::Params at some other point in the middleware chain. More than
    that, the ordering was what decided if it worked.
    
    The following ordering did not work, even though it's the logical placement for
    an exception handling middleware:
    
    ```ruby
    class API < Goliath::API
      use ExceptionHandlingMiddleware
      use Goliath::Rack::Params
      use MiddlewareThatWasRaisingAnException
    
      # ...
    end
    ```
    
    I would hit an endpoint, get back a nicely-wrapped HTTP 500 error with the
    message raised by MiddlewareThatWasRaisingAnException, but the
    ExceptionHandlingMiddleware wasn't doing any of the exception handling.
    
    This ordering *did* work, though:
    
    ```ruby
    class API < Goliath::API
      use Goliath::Rack::Params
      use ExceptionHandlingMiddleware
      use MiddlewareThatWasRaisingAnException
    
      # ...
    end
    ```
    
    I would hit an endpoint, get back the HTTP 500 error with the right message,
    and the ExceptionHandlingMiddleware was doing its processing.
    
    As it turns out, the culprit was Goliath::Rack::Params itself. Previously,
    Goliath::Rack::Params would delegate down the chain with an @app.call(env), but
    wrap *that* call in a Goliath::Rack::Validator.safely block. Therefore, any
    exceptions raised downstream would get rescued, and the error response
    generated by Goliath::Rack::Validator.safely was ultimately returned as the API
    response - no exceptions raised for the ExceptionHandlingMiddleware to handle.
    
    But really, the only errors that the Goliath::Rack::Params middleware should be
    rescuing have to do with parsing the params. So, quite simply, this commit
    moves the @app.call(env) out of the Goliath::Rack::Validator.safely block. If
    there was an error in parsing the params, we avoid delegating to @app and
    instead just return the validation error response. If there is an exception
    raised by @app.call(env), upstream middleware will see it.
    
    Ultimately, if an exception raised by the @app.call(env) in
    Goliath::Rack::Params is not handled by upstream middleware (like in my
    proposed use case), we're still safe because the likes of Goliath::API#call and
    Goliath::Request#process ensure that any unhandled errors will get rescued and
    result in some sort of Rack response.
Commits on Apr 7, 2015
  1. Merge pull request #313 from StevenNunez/patch-1

    igrigorik committed Apr 7, 2015
    Update link to screencast
Commits on Mar 19, 2015
  1. Merge pull request #309 from aenain/feature-event-stream-test-helper

    igrigorik committed Mar 19, 2015
    Add test_helper_sse to make it easier to test event streams.
Commits on Mar 14, 2015
Commits on Feb 11, 2015
  1. Merge pull request #306 from rb2k/patch-1

    igrigorik committed Feb 11, 2015
    Add Ruby 2.2.0 to the travis build
Commits on Jan 2, 2015
  1. Merge pull request #305 from fatum/master

    igrigorik committed Jan 2, 2015
    Add einhorn guide link
  2. Update README.md

    fatum committed Jan 2, 2015
Commits on Jan 1, 2015
  1. Merge pull request #304 from fatum/socket-manager

    igrigorik committed Jan 1, 2015
    Add zero-downtime restarts
  2. Require einhorn

    fatum committed Jan 1, 2015
  3. Remove debug

    fatum committed Jan 1, 2015
Commits on Dec 12, 2014
  1. Merge pull request #303 from ajvondrak/master

    dj2 committed Dec 12, 2014
    Fix for issue #302
  2. #302: adjust Content-Length header (if present) to account for new JS…

    ajvondrak committed Dec 12, 2014
    …ONP response body; fixes specs
Commits on Jul 21, 2014
  1. Merge pull request #294 from Juanmcuello/fix-stdout-log

    dj2 committed Jul 21, 2014
    Correctly suffix stdout logfile name with 'stdout' string.
Commits on Jul 18, 2014
Commits on Jun 22, 2014
  1. bump to 1.0.4

    igrigorik committed Jun 22, 2014
    Changelog:
    v1.0.3...master
Commits on Apr 27, 2014
Commits on Apr 15, 2014
  1. Merge pull request #290 from rezwyi/fix_api_proxy_example

    nolman committed Apr 15, 2014
    Add missed line of code to examples/api_proxy.rb
Commits on Apr 5, 2014
  1. Add missed line of code

    rezwyi committed Apr 5, 2014
Commits on Jan 31, 2014
  1. Merge pull request #281 from Juanmcuello/goliath-env

    igrigorik committed Jan 31, 2014
    Remove GOLIATH_ENV thread local from connection setup,
Commits on Jan 30, 2014
  1. Remove GOLIATH_ENV thread local from connection setup,

    Juanmcuello committed Jan 30, 2014
    There is no need to set it here, as it's set later in API class.
    
    See also #279
Commits on Jan 13, 2014
  1. Merge pull request #278 from bobes/master

    dj2 committed Jan 13, 2014
    Update required http_parser.rb gem version to prevent collision with em-http-request
Commits on Jan 8, 2014
  1. Merge pull request #277 from marcoow/master

    dj2 committed Jan 8, 2014
    - guard ~> 2.0 depends on listen ~> 2.0 which requires Ruby 1.9.3 so that breaks the build fr 1.9.2
    - the web socket test expects the data directly while #receive returns a WebSocket::Frame::Incoming::Client (probably due to a change in em-websocket I guess?)
    - the "stopping server..." log message seems to have been removed so I removed the assertion