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
