yahns will use kcar as a request parser

yahns will use kcar as a request parser

[Eric Wong]

Hello to folks interested in either yahns and kcar.

For those of you unfamiliar with either, kcar is currently an
HTTP response parser which converts arbitrary bytestreams to
Rack-compatible response status and headers (and optionally
body chunk filtering).

yahns currently uses an HTTP request parser from a well-known
HTTP server; but kcar for the optional reverse HTTP proxying
capability.

kcar is derived from the HTTP request parser used by yahns; so
there is enough common code between HTTP 1.x request and
response parsing to stick them into the same object.  Using kcar
for request parsing will transparently reduce icache footprint
and allow wider object recycling (should yahns go down that path);
as well as reducing installation time and footprint.

Since neither project is particularly popular at the moment,
there'll be more room to experiment with potential performance
improvements and memory usage reductions.

https://yhbt.net/yahns/README
	mail archives: https://yhbt.net/yahns-public/
	git clone git://yhbt.net/yahns

https://bogomips.org/kcar/
	mail archives: https://bogomips.org/kcar-public/
	git clone git://bogomips.org/kcar

Fwiw, yahns has been hosting both sites since late-2013.

Re: yahns will use kcar as a request parser

[Eric Wong]

The current parser used by yahns interprets X-Forwarded-Proto
and X-Forwarded-Ssl headers to set rack.url_scheme in the
rack request env.

Since these are non-standard headers, I think we can safely drop
support for them in yahns.  Neither passenger, puma, nor thin
seem to respect them when setting rack.url_scheme, either...

Anyways, these headers are used by Rack::Request,
and RFC 7239 ("Forwarded" header) was standardized in 2014,
so maybe some people would rather use that instead, too...