Date | Commit message (Collapse) |
|
Might as well... this has been in use at YHBT.net for ~4 years
at this point. And given nginx has new corporate overlords,
maybe a decidedly non-enterprisey alternative is worth
"marketing" :P
Previous discussion from 2016:
https://YHBT.net/yahns-public/20160220081619.GA10850@dcvr.yhbt.net/
|
|
"call" is a generic name and may not obvious to somebody
new to the code.
|
|
In case somebody stumbles upon it...
|
|
We cannot rely on env being available after proxy_wait_next
|
|
This will allow us to add extra options at the response
layer without taking up extra env hash keys.
|
|
Ugh, this is a little slower, but some people will want to
forward through multiple proxies.
|
|
This makes the ReqRes class easier-to-find and hopefully
maintain when using with other parts of yahns, although there
may be no reason to use this class outside of ProxyPass.
|
|
The cost of extra branches inside a loop is negligible compared
to the cost of all the other method calls we make. Favor
smaller code instead and inline some (now) single-use methods.
Furthermore, this allows us to reuse the request header buffer
instead of relying on thread-local storage and potentially
having to to swap buffers.
|
|
We don't want to wait on GC to reap sockets on errors,
generational GC in Ruby is less aggressive about reaping
long-lived objects such as long-lived HTTP connections.
|
|
This allows backend application servers to set "rack.url_scheme"
as appropriate using Rack::Request#scheme.
Plack/PSGI users can also take advantage of this using
Plack::Middleware::ReverseProxy
|
|
Using the 'update-copyright' script from gnulib[1]:
git ls-files | UPDATE_COPYRIGHT_HOLDER='all contributors' \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
xargs /path/to/gnulib/build-aux/update-copyright
We're also switching to 'GPL-3.0+' as recommended by SPDX
to be consistent with our gemspec and other metadata
(as opposed to the longer but equivalent "GPLv3 or later").
[1] git://git.savannah.gnu.org/gnulib.git
|
|
There are likely yet-to-be-discovered bugs in here.
Also, keeping explicit #freeze calls for 2.2 users, since most
users have not migrated to 2.3, yet.
|
|
We do not expose any sort of API beyond what's in the config file
manpage to our users. Do not mislead them into thinking we
currently have a stable API (though I'm considering one).
This avoids wasting disk space and installation time for users who
do not have a: "gem: --no-ri --no-rdoc" line in their ~/.gemrc
|
|
Clients may disconnect on us while we're writing the response
here, so we should shut the backtrace up to avoid polluting
logs.
|
|
We shouldn't blindly pass the "Server" tag through, since we may
be proxying Apache instances and we don't want to misadvertise,
either.
IMHO, it is best to say nothing at all to save bandwidth and
reduce the potential for attackers in case a vulnerability is
discovered in yahns.
|
|
It does not release memory immediately and GC can handle it
reliably, so don't waste a constant lookup + cache entry on it.
While we're at it, explain why we can't do a simpler
respond_to? check instead.
|
|
Arrays are less verbose, but they have more bytecode overhead
which actually matters at runtime.
|
|
No point in wasting space and reducing code clarity with this
method to remove references to live objects.
|
|
Bad connections or dead upstreams cannot be solved looking at a
backtrace, so avoid polluting logs with them and making other
problems less visible.
|
|
Upstreams may shut us down while we're writing a request body,
attempt to forward any responses from the upstream back to the
client which may explain the rejection reason for giant uploads.
|
|
This giant method needs to spew an error response in case uploads
to the upstream fail, ensure the local variable is defined early.
|
|
A dumb string comparison will do here, so there's no point
in paying the memory and CPU cost of a regexp match when we
already extracted the suffix from a header key.
|
|
hijack seems incompatible with many middlewares, so return a
wonky response tuplet just in case...
|
|
We cannot pass trailers from upstreams to HTTP/1.0 clients without
fully-buffering the response body AND trailers before forwarding the
response header.
Of course, one of the reasons yahns exists is to support lazy
buffering, so fully-buffering up front is wasteful and hurts
latency. So instead, degrade to 1.0 requests to upstreams for
HTTP/1.0 clients, this should prevent upstreams from sending
trailers in the first place.
HTTP/1.0 clients on Rails apps may suffer, but there probably
are not too many HTTP/1.0 clients out there.
|
|
Rack apps may (through a round-about way) send HTTP trailers
to HTTP/1.1 clients, and we need a way to forward those responses
through without losing the trailers.
|
|
We were incorrectly stashing the return value of detach_rbuf!
into the inter-thread buffer buffer which is bound to the client.
|
|
This allows our reverse proxy to avoid having an innefficient 1:1
relationship between threads and upstream connections, reducing
memory usage when there are many upstream connections (possibly to
multiple backend machines).
|
|
This will rely on rack.hijack in the future to support
asynchronous execution without tying up a thread when waiting
for upstreams. For now, this allows simpler code with fewer
checks and the use of monotonic time on newer versions of Ruby.
|