about summary refs log tree commit homepage
path: root/test/unit/test_http_parser_ng.rb
DateCommit message (Collapse)
2010-10-05http: raise empty backtrace for HttpParserError
It's expensive to generate a backtrace and this exception is only triggered by bad clients. So make it harder for them to DoS us by sending bad requests.
2010-06-08http: ignore Version: header if explicitly set by client
When Unicorn receives a request with a "Version" header, the HttpParser transforms it into "HTTP_VERSION". After that tries to add it to the request hash which already contains a "HTTP_VERSION" key with the actual http version of the request. So it tries to append the new value separated by a comma. But since the http version is a freezed constant, the TypeError exception is raised. According to the HTTP RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1) a "Version" header is valid. However, it's not supported in rack, since rack has a HTTP_VERSION env variable for the http version. So I think the easiest way to deal with this problem is to just ignore the header since it is extremely unusual. We were getting it from a crappy bot. ref: http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps@mail.gmail.com Acked-by: Eric Wong <normalperson@yhbt.net>
2010-06-03test: http_parser_ng: fix broken assertion
This was noticed by running under Ruby 1.9.2-preview3
2010-04-26http: pedantic fix for trailer-less chunked requests
HTTP requests without trailers still need a CRLF after the last chunk, that is: it must end as: "0\r\n\r\n", not "0\r\n". So we'll always pretend there are trailers to parse for the sake of TeeInput. This is mostly a pedantic fix, as the two bytes in the socket buffer are unlikely to trigger protocol errors.
2010-04-19http: negative/invalid Content-Length raises exception
...instead of tripping an assertion. This fixes a potential denial-of-service for servers exposed directly to untrusted clients. This bug does not affect supported Unicorn deployments as Unicorn is only supported with trusted clients (such as nginx) on a LAN. nginx is known to reject clients that send invalid Content-Length headers, so any deployments on a trusted LAN and/or behind nginx are safe. Servers affected by this bug include (but are not limited to) Rainbows! and Zbatery. This does not affect Thin nor Mongrel which never got request body filtering treatment that the Unicorn HTTP parser got in August 2009.
2010-02-08test_http_parser_ng: remove redundant "coding: binary"
we've already got "-*- encoding: binary -*-" in everything
2009-12-06http: PATH_INFO/REQUEST_PATH includes semi-colons
This is allowed according to RFC 2396, section 3.3 and matches the behavior of URI.parse, as well.
2009-11-04http: extra test for bytewise chunked bodies
Make sure we're completely resumable no matter how idiotic clients are.
2009-11-04http: allow headers/trailers to be written byte-wise
This allows clients to trickle headers and trailers. While Unicorn itself does not support slow clients for many reasons, this affects servers that depend on our parser like Rainbows!. This actually does affect Unicorn when handling trailers, but HTTP trailers are very ever rarely used in requests. Fortunately this stupid bug does not seem able to trigger out-of-bounds conditions.
2009-09-08"encoding: binary" comments for all sources (1.9)
This ensures any string literals that pop up in *our* code will just be a bag of bytes. This shouldn't affect/fix/break existing apps in most cases, but most constants will always have the "correct" encoding (none!) to be consistent with HTTP/socket expectations. Since this comment affects things only on a per-source basis, it won't affect existing apps with the exception of strings we pass to the Rack application. This will eventually allow us to get rid of that Unicorn::Z constant, too.
2009-09-03http: add HttpParser#headers? method
This method determines if there are headers in the request. Simple HTTP/0.9 requests did not have headers in the request (and our responses we make should not have them, either).
2009-09-02http: SERVER_PROTOCOL matches HTTP_VERSION
And it'll default to HTTP/0.9 if HTTP_VERSION is not specified (as version-less HTTP requests imply HTTP/0.9.
2009-09-02test_http_parser_ng: fix failing HTTP/0.9 test case
SERVER_PROTOCOL is actually defined as "HTTP/1.1 even though it should not be for HTTP/0.9 responses.
2009-09-01http: support for simple HTTP/0.9 GET requests
HTTP/0.9 only supports GET requests and didn't require a version number in the request line. Additionally, only a single CRLF was required. Note: we don't correctly generate HTTP/0.9 responses, yet.
2009-08-11http: add "HttpParser#keepalive?" method
This should be used to detect if a request can really handle keepalives and pipelining. Currently, the rules are: 1. MUST be a GET or HEAD request 2. MUST be HTTP/1.1 3. MUST NOT have "Connection: close" set This also reduces the amount of garbage we create by globalizing constants and using them whenever possible.
2009-08-10http: rename read_body to filter_body
This method is strictly a filter, it does no I/O so "read" is not an appropriate name to give it.
2009-08-09http: join repeated headers with a comma
Since Rack requires a Hash object, this is joined in in accordance with rfc2616, section 4.2[1]. Of course, it's up to the framework or application to handle such requests. I could optimize this to avoid creating a single garbage String object, but I don't think it's common enough to worry about... [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
2009-08-09http: add test for invalid trailer
Just in case clients decide to get cute.
2009-08-09http: unit tests for overflow and bad lengths
We're bound by the maximum value of off_t when handling input bodies (we need to buffer to disk). Also ensure we stop bad clients that send us unparseable lengths.
2009-08-09http: preliminary chunk decoding