From: Eric Wong <firstname.lastname@example.org> To: "Lin Jen-Shin (godfat)" <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [RFC] proxy_pass: document as public API Date: Sat, 20 Feb 2016 09:41:02 +0000 [thread overview] Message-ID: <20160220094102.GA26634@dcvr.yhbt.net> (raw) In-Reply-To: <CAA2_N1s-YwUZtNM+Q1tYxfkdTU+BDsjpR_YYh86i1QFOVmQ9PA@mail.gmail.com> "Lin Jen-Shin (godfat)" <email@example.com> wrote: > On Sat, Feb 20, 2016 at 4:16 PM, Eric Wong <firstname.lastname@example.org> wrote: > > Any thoughts? So far I've resisted having a public API. > > On the other hand, the current state of ProxyPass being a > > Rack app using rack.hijack still has nasty limitations > > such as incompatibility with any existing middleware. > > Something simple such as access logs won't work well > > (e.g. Rack::CommonLogger or Clogger) > > My first impression was that why not put this in a separate > gem, say yahns-apps or so? I am not saying we should do > this, just curious why? Easier to maintain and distribute? Yes, easier to maintain + distribute since it depends on yahns internals. > > On the other hand, it would be nice to have a mostly-Ruby > > alternative to nginx today... > [...] > > I am even more curious to this. Nginx is pretty accessible already, > (perhaps not on Windows though?) and it would surely be more > performant than Ruby. Or is it because we might want to make it > not only a reverse proxy, extending it with Rack middleware? I'm not up-to-date with current nginx versions, but proxy output buffering in nginx could not be lazy when I checked. It had to either not buffer at all or buffer entirely (the default) before writing to the client. Also, being a Rack app also means an app could migrate thread-safe endpoints to yahns (running normal Rack directly), while forwarding non-thread-safe endpoints to unicorn or whatever else. nginx has a better chance of working on Windows than yahns :) I've always been openly against wasting time on non-Free OSes. > If so, then we probably don't want this directive: > > app(:proxy_pass) > > but just treat it as a Rack application? Or we might want to define > another middleware, say proxy_pass's middleware, which would > be slightly different than the rack ones? If so I think it makes a lot > of sense to have app(:proxy_pass). Right, I'm leaning towards leaving it as a Rack app. If we want to define a new middleware API, it would be a new ecosystem. If that were easy, Rack would've done it by now :) So perhaps it's better to provide some sort of API (like the (seemingly abandoned) rack_after_reply RubyGem) which which existing middlewares could be slightly modified to opt-in to. Fwiw, I mainly want to use clogger with this for access logs <http://clogger.bogomips.org/>. I believe other application logic should reside in the application server, including things like Rack::Deflater. Anyways, I'd prefer to move slowly and cautiously with this so I'm unlikely to finalize anything before April or even May.
prev parent reply other threads:[~2016-02-20 9:41 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-20 8:16 Eric Wong 2016-02-20 8:37 ` Lin Jen-Shin (godfat) 2016-02-20 9:41 ` Eric Wong [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://yhbt.net/yahns/README * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160220094102.GA26634@dcvr.yhbt.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC] proxy_pass: document as public API' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: ../../yahns.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).