Re: unicorn log attack?

[Lawrence Pit <lawrence.pit@gmail.com>]

Hi Eric,

> but that includes emails :)

Yeah, sorry about the email format :[  Hope this time it's as expected.

> Since the backtrace below clearly shows the error happened from
> something your application was doing;

.. if you count ruby MRI and rack as my application. ;) All this
happens way before it touches what I would call my application. But
yes, I could insert my own middleware before the first rack middleware
and deal with it.

> I don't consider it the responsibility of the app server to sanitize it.

fwiw, I agree :) ... similarly, why consider it the responsibility of
the app server to log it?  it is an application level error, not a
unicorn error.

Rack's spec doesn't state how to deal with exceptions in return to
@app.call. Python's PEP 0333 says a bit more, along the lines of that
applications should try to trap their own, internal errors. I'll go
for that then.


PS.

> In ancient times (perhaps it was the Mongrel days), the server
> itself would dump the contents of bad HTTP requests for
> debugging; but given the amount of probes/scans I saw: it wasn't
> worth it.  We don't even log things like aborted/dropped
> connections.

Yes, nice. :)

The request I'm seeing is also a bad HTTP request (invalid
%-encoding). To illustrate:

curl -v -X POST "http://localhost:8080/?foo=bar%0abaz%xx"

will have unicorn responds with a 400 Bad Request, handling
Unicorn::HttpParserError. The request doesn't enter @app.call(...).
And indeed unicorn doesn't even bother logging anything about this
request.

When sending the same thing as form data:

curl -v -X POST -d "foo=bar%0abaz%xx" "http://localhost:8080/"

then this will result in a 500 error and unicorn will log the posted
value and stacktrace (provided Rack::Request.new(env).POST is called
anywhere and @app doesn't trap its own errors):

app error: invalid %-encoding (bar%0abaz%xx)
(Rack::Utils::InvalidParameterError)


Cheers,
Lawrence