| Date | Commit message (Collapse) |
|---|
|
There's no need to use a goto here to avoid one level of
nesting.
|
|
This should make code easier to read and follow.
|
|
In case we modify our struct to not use bitflags, this should
make it easier to change the parser code. This also adds extra
clarification for how we track keepalive and why we only do it
for certain request methods.
|
|
These are similar to the macros found in MRI, and
can more easily allow us to swap out the bitflags
for real struct members...
|
|
Avoid a negative conditional in the process and having an
explicit else in there makes this piece easier to track.
Also explain /why/ the Host: header can get ignored.
|
|
Just pass the http_parser struct pointer when checking for
invalid headers in the trailer. The compiler should be smart
enough to inline and not relookup the flags. This avoids having
to worry about the flags being signed or not (they should never
be) and also makes it easier to maintain if we move away from
using bitfields.
|
|
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).
|
|
And it'll default to HTTP/0.9 if HTTP_VERSION is not specified
(as version-less HTTP requests imply HTTP/0.9.
|
|
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.
|
|
ref: rfc 2616, section 5.1.1
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1
Current version of Rack::Lint agrees with us, too. While
I've yet to encounter actual usage of non-upper REQUEST_METHODs,
we might as well support what Rack supports.
|
|
neither buffer nor p should be const (since we modify buffer in
$snake_upcase_char), but this is a much smaller change _for now_
|
|
While I still consider pound to be irrelevant, but I still
sometimes get hand-crafted HTTP requests that come in with
multiline headers. Since these are part of the HTTP specs and
not difficult to support, we might as well support them for
the sake of completeness.
|
|
Ruby strings may be copy-on-write (multiple #dup'ed strings can
point to the same internal buffers). So since
HttpParser#headers modifies its buffer argument, we'll need to
make sure the String object we have points to its own private
buffer.
This doesn't affect Unicorn except in a to-be-written test case
that relies on a #dup'ed String.
|
|
* Documented Unicorn::HttpParser API methods
* Keep GPL2 (COPYING) as-is without RDoc formatting.
* The auto-generated index.html is stupid, replace it with
README which looks saner.
|
|
ab still sends this with HTTP/1.0 requests, which is
unfortunate, but synthetic benchmarks are good for marketing
purposes!
|
|
We need to declare constants for 64-bit off_t explicitly with
the "LL" suffix on 32-bit machines.
|
|
Otherwise we'll be creating an extra garbage string because
rb_hash_aset can't tell the string isn't being used elsewhere
and creates a new frozen one.
|
|
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.
|
|
For comparing a raw memory space against a constant
|
|
This method is strictly a filter, it does no I/O so "read"
is not an appropriate name to give it.
|
|
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
|
|
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.
|
|
This should be more robust, faster and easier to deal
with than the ugly proof-of-concept regexp-based ones.
|
|
|
|
Explicitly track if our request will need Content-Length
or chunked body decoding.
|
|
The macro version lets us painlessly compare Ruby strings
against constant C strings. It wraps a C version of the
function which is necessary to avoid double evaluation while
preventing the user from having to type sizeof or strlen.
|
|
We'll need to keep track of a few more things to account
for content/chunk length and the temporary file descriptor
we'll need to use.
|
|
|
|
It's easy enough to just check a single equality without having
extra functions obscuring what's actually going on.
|
|
We'll need to be defining g_http_transfer_encoding and
g_content_length in the near future.
|
|
Just extra noise we don't care about. This also allows us to
undef the DEF_GLOBAL macro to avoid polluting the main
namespace.
|
|
It's mostly uninteresting code.
|
|
Create a Ruby string object before jumping into the function
to reduce the number of parameters passed and to take advantage
of our STR_NEW macro to reduce noise.
|
|
|
|
It doesn't conflict with any any common variables, tokens or
documentation pieces in the code.
|
|
Eliminate unnecessary jumping around in the source code to find
actions that lead to other actions and making it harder to
notice side effects when dealing with data we're sharing anyways.
|
|
There's also no point in validating field hits if our field is a
common field; so only do the validation for field length if we
need to allocate memory for a new field.
|
|
The "_value" suffix was used to denote the return type, which is
redundandant as it is already known at compile time (being that
this is C and functions have explicit return types). Furthurmore,
the "_value" is confusing since we're actually returning a "key"
when "value" is used in the context of "key-value" pairs.
|
|
More tightly integrate the C/Ruby portions with C/Ragel to avoid
the confusing the flow. Split out some files into hopefully
logical areas so it's easier to focus on more
interesting/volatile code.
|
|
Only fallback to check_sizeof() if it is not. check_sizeof() is
broken in Ruby 1.9.2preview1 (but fixed in trunk).
|
|
We'll be needing the UH_OFF_T_MAX define for the chunked
body handling and rb_str_set_len may be needed as well.
|
|
It's too annoying to have to deal with long prefixes that all
look alike. "g_" is fairly standard in C programs so I'm
keeping it (even though eliminating the prefix entirely is
preferable, but there'd be name conflicts I don't feel like
resolving).
|
|
So that blame falls on Eric if stuff breaks.
|
|
typedefs can be misleading for aggregate types, a struct is a
struct.
|
|
But keep it in the Manifest
|
|
Use Data_Make_Struct instead of Data_Wrap_Struct to avoid extra
steps/code in object allocation. The GC will also free()
implicitly if no free callback is passed to Data_Make_Struct,
and we don't need an extra method here...
Since we're more comfortable with object management nowadays,
just make the data_get() fail with an assertion failure if it
somehow (very unlikely) ends up getting a NULL parser object.
Unicorn itself has no way of recovering other than throwing
errors to clients anyways and we have bigger problems if there's
a GC bug causing this.
Then, finally, reduce the size of our http_parser struct even
more (we'll add an int back later) since we know it's safe to
do so...
|
|
We couldn't do proper namespacing for the C module so there was
a potential conflict with Init_http11() in Mongrel. This was
needed because Mongrel's HTTP parser could be used in some
applications and we may be unfortunate enough need to support
them.
|
|
No point in making syscalls to deal with empty bodies.
Reinstate usage of the NULL_IO object which allows us
to avoid allocating new objects.
|
|
They aren't common, but apparently there exist
URLs with them, so we'll support them.
|
|
We now parse the scheme, host and port from Absolute URIs and
ignore them if the equivalents are specified in the other
headers.
|