| Date | Commit message (Collapse) |
|---|
|
* strip trailing and leading linear whitespace in headers
* improve Ruby 1.9.3dev compatibility
|
|
Librelist is a non-profit service and .org makes that clearer.
|
|
This is required since Ruby 1.9.3dev if the size of the
string doesn't change.
|
|
RFC 2616, section 4.2:
> The field-content does not include any leading or trailing LWS:
> linear white space occurring before the first non-whitespace
> character of the field-value or after the last non-whitespace
> character of the field-value. Such leading or trailing LWS MAY be
> removed without changing the semantics of the field value. Any LWS
> that occurs between field-content MAY be replaced with a single SP
> before interpreting the field value or forwarding the message
> downstream.
|
|
|
|
|
|
Nobody sets it, so discourage new users from setting it since
it's stupid :P.
|
|
Internal cleanups and micro-optimizations. We are fully-supported
under Ruby 1.9.3dev and Rubinius 1.2.2
|
|
Omitting those seems to work fine with RubyGems
|
|
|
|
And parallel builds.
|
|
Whee!
|
|
rb_str_update and rb_str_flush have been gone for
ages, now.
|
|
Prettier this way
|
|
From mall.git
|
|
We're not an HTTP client and will likely never be.
|
|
Not that we'll ever deal with monster strings in
HTTP headers...
|
|
This minimizes allocations made at runtime and uses
ivars for faster access under 1.9
|
|
Oops!
|
|
Whee!
|
|
pkg_extra should be appended-to, only
|
|
Otherwise we become undocumented! :<
|
|
It's easier on me, and we can drop JavaScript from our site!
|
|
1.9.3dev is stricter and that's awesome
|
|
* header/body-less pipelined HTTP/1.1 responses handled properly
Some HTTP servers do not send any response headers
for errors, only the HTTP status line.
|
|
Some HTTP servers do not send any response headers
for errors, only the HTTP status line.
|
|
It could be something else...
|
|
Our handling of pipelined identity (not chunked) responses
did not properly reset our internal buffer, causing HTTP
header parsing to fail for the second response as the buffer
still contained the last part of the body from the previous
response.
There are also minor documentation updates and cleanups.
|
|
Kcar::Parser#extract_trailers never returns a false/nil
value, so there's no reason to check for it.
|
|
When parsing a stream of multiple responses (when HTTP
pipelining is enabled), we did not properly reset our
internal buffer, causing failures when parsing the
second response.
|
|
Oops :x
|
|
It has likely always worked.
|
|
|
|
|
|
Oops, URLs should end with a trailing slash since I'm expecting
my webserver to load index.html. Also, it's "kcar hackers",
kcar did not write itself!
|
|
|
|
Kcar::Response may not be useful for people that eventually use
EventMachine or Rev.
|
|
Any regexps or temporary strings should be created with binary
encoding as that's how HTTP processing is done.
|
|
|
|
We can't unchunk bodies and still say
"Transfer-Encoding: chunked", nor can we say we have Trailers
without chunked encoding. So we'll unconditionally disable
unchunking and pass the response through as-is
|
|
|
|
|
|
It's not a real "session" since it does not have any facilities
to write responses.
|
|
|
|
|
|
This function can get intimidating to new users
|
|
|
|
|
|
We avoid filter_body overhead for things with known
content-length.
|
|
|