about summary refs log tree commit homepage
path: root/test/unit/test_http_parser_ng.rb
DateCommit message (Collapse)
2017-02-15Revert "remove response_start_sent"
Oops, this was a half-baked change I was considering but forgot about. This reverts commit 69fd4f9bbff3708166fbf70163fa6e192dde1497.
2017-02-13remove response_start_sent
2015-06-06http: move response_start_sent into the C ext
Combined with the previous commit to eliminate the `@socket' instance variable, this eliminates the last instance variable in the Unicorn::HttpRequest class. Eliminating the last instance variable avoids the creation of a internal hash table used for implementing the "generic" instance variables found in non-pure-Ruby classes. Method entry overhead remains the same. While this change doesn't do a whole lot for unicorn memory usage where the HttpRequest is a singleton, it helps other HTTP servers which rely on this code where thousands of clients may be connected.
2015-03-02http: remove experimental dechunk! method
It was never used anywhere AFAIK and wastes precious bytes.
2015-02-06fix uninstalled testing and reduce require paths
This fixes a bug introduced in commit fe83ead4eae6f011fa15f506cd80cb4256813a92 (GNUmakefile: fix clean gem build + reduce build cruft) which broke clean Ruby installations without an existing unicorn gem installed :x
2014-09-17http: reduce parser from 72 to 56 bytes on 64-bit
This allows the parser struct to fit in one cache line on x86-64 systems where cache lines are 64 bytes. Using 32-bit integer lengths is safe here because these are only for tracking offsets within the HTTP header buffer. We can safely limit HTTP headers and in-memory buffers to be less than 4GB without anybody complaining. HTTP bodies continue to use off_t (usually 64-bit, even on 32-bit systems) sizes and support as much as the OS/hardware can handle.
2014-08-18http: remove the keepalive requests limit
This was a hack for some event loops such as those found in nginx and some Rainbows! concurrency models. Using epoll/kqueue with one-shot notification (which yahns does) avoids all fairness problems.
2013-05-08HttpParser#next? becomes response_start_sent-aware
This could allow servers with persistent connection support[1] to support our check_client_connection in the future. [1] - Rainbows!/zbatery, possibly others
2012-11-13tests: remove assert_nothing_raised (part 2)
assert_nothing_raised ends up hiding errors and backtraces, making things harder to debug. Since Test::Unit already fails on uncaught exceptions, there is no need to assert on the lack of exceptions for a successful test run. This is a followup to commit 5acf5522295c947d3118926d1a1077007f615de9
2011-12-17http: test case for "Connection: TE"
We need to be sure we don't barf on this header.
2011-06-13http: dechunk! method to enter dechunk mode
This allows one to enter the dechunker without parsing HTTP headers beforehand. Since we skipped header parsing, trailer parsing is not supported since we don't know what trailers might be (to our knowledge, nobody uses trailers anyways)
2011-02-03test/unit: fix tests under Ruby 1.9.3dev
Ugh, one day I'll clean them up, one day...
2011-01-05http_parser: add clear method, deprecate reset
But allows small optimizations to be made to avoid constant/instance variable lookups later :)
2010-12-30tests: test parser works with keepalive_requests=0
We use this in Rainbows! to disable keepalive in certain configurations.
2010-12-26http: #keepalive? and #headers? work after #next?
We need to preserve our internal flags and only clear them on HttpParser#parse. This allows the async concurrency models in Rainbows! to work properly.
2010-12-20http: support keepalive_requests directive
This limits the number of keepalive requests of a single connection to prevent a single client from monopolizing server resources. On multi-process servers (e.g. Rainbows!) with many keepalive clients per worker process, this can force a client to reconnect and increase its chances of being accepted on a less-busy worker process. This directive is named after the nginx directive which is identical in function.
2010-12-19http: delay clearing env on HttpParser#next?
This allows apps/middlewares on Rainbows! that rely on env in the response_body#close to hold onto the env.
2010-11-11http_parser: ensure keepalive is disabled when reset
We'll need this in Rainbows!
2010-11-06http_parser: add HttpParser#next? method
An easy combination of the existing HttpParser#keepalive? and HttpParser#reset methods, this makes it easier to implement persistence.
2010-11-06enable HTTP keepalive support for all methods
Yes, this means even POST/PUT bodies may be kept alive, but only if the body (and trailers) are fully-consumed.
2010-10-07http: fix behavior with pipelined requests
We cannot clear the buffer between requests because clients may send multiple requests that get taken in one read()/recv() call.
2010-10-07http: allow this to be used as a request object
The parser and request object become one and the same, since the parser lives for the lifetime of the request.
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