yahns Ruby server user/dev discussion
 help / color / mirror / code / Atom feed
* [RFC] proxy_pass: possibly avoid breaking some middlewares
@ 2015-04-07 21:34 Eric Wong
  2015-04-08 10:38 ` Lin Jen-Shin (godfat)
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Wong @ 2015-04-07 21:34 UTC (permalink / raw)
  To: yahns-public

Running this on http://yhbt.net/yahns-public/ for now.  I originally I
forgot to disable one of my throwaway middlewares which was not aware of
Rack hijacking.

From: Eric Wong <e@80x24.org>
Subject: [PATCH] proxy_pass: possibly avoid breaking some middlewares

hijack seems incompatible with many middlewares, so return a
wonky response tuplet just in case...
---
 lib/yahns/proxy_pass.rb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/yahns/proxy_pass.rb b/lib/yahns/proxy_pass.rb
index e3ba7f0..48a61af 100644
--- a/lib/yahns/proxy_pass.rb
+++ b/lib/yahns/proxy_pass.rb
@@ -235,6 +235,9 @@ class Yahns::ProxyPass # :nodoc:
 
     # finally, prepare to emit the headers
     rr.req_start(c, req << "\r\n".freeze, input, chunked)
+
+    # this probably breaks fewer middlewares than returning whatever else...
+    [ 500, [], [] ]
   rescue => e
     Yahns::Log.exception(env['rack.logger'], 'proxy_pass', e)
     [ 502, [ %w(Content-Length 0), %w(Content-Type text/plain) ], [] ]
-- 
EW


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] proxy_pass: possibly avoid breaking some middlewares
  2015-04-07 21:34 [RFC] proxy_pass: possibly avoid breaking some middlewares Eric Wong
@ 2015-04-08 10:38 ` Lin Jen-Shin (godfat)
  2015-04-08 17:03   ` Eric Wong
  0 siblings, 1 reply; 5+ messages in thread
From: Lin Jen-Shin (godfat) @ 2015-04-08 10:38 UTC (permalink / raw)
  To: Eric Wong; +Cc: yahns-public

On Wed, Apr 8, 2015 at 5:34 AM, Eric Wong <e@80x24.org> wrote:
> Running this on http://yhbt.net/yahns-public/ for now.  I originally I
> forgot to disable one of my throwaway middlewares which was not aware of
> Rack hijacking.
>
> From: Eric Wong <e@80x24.org>
> Subject: [PATCH] proxy_pass: possibly avoid breaking some middlewares
>
> hijack seems incompatible with many middlewares, so return a
> wonky response tuplet just in case...
> ---
>  lib/yahns/proxy_pass.rb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/lib/yahns/proxy_pass.rb b/lib/yahns/proxy_pass.rb
> index e3ba7f0..48a61af 100644
> --- a/lib/yahns/proxy_pass.rb
> +++ b/lib/yahns/proxy_pass.rb
> @@ -235,6 +235,9 @@ class Yahns::ProxyPass # :nodoc:
>
>      # finally, prepare to emit the headers
>      rr.req_start(c, req << "\r\n".freeze, input, chunked)
> +
> +    # this probably breaks fewer middlewares than returning whatever else...
> +    [ 500, [], [] ]

You probably meant [ 500, {}, [] ] here?

>    rescue => e
>      Yahns::Log.exception(env['rack.logger'], 'proxy_pass', e)
>      [ 502, [ %w(Content-Length 0), %w(Content-Type text/plain) ], [] ]
> --
> EW
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] proxy_pass: possibly avoid breaking some middlewares
  2015-04-08 10:38 ` Lin Jen-Shin (godfat)
@ 2015-04-08 17:03   ` Eric Wong
  2015-04-08 17:23     ` Lin Jen-Shin (godfat)
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Wong @ 2015-04-08 17:03 UTC (permalink / raw)
  To: Lin Jen-Shin (godfat); +Cc: yahns-public

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> On Wed, Apr 8, 2015 at 5:34 AM, Eric Wong <e@80x24.org> wrote:
> > +    # this probably breaks fewer middlewares than returning whatever else...
> > +    [ 500, [], [] ]
> 
> You probably meant [ 500, {}, [] ] here?

No, arrays work fine, Rack headers just need to respond to #each
with key + value strings.

I prefer Arrays since they use less memory per-entry, but here they're
the same cost when empty.

But I'm also likely to revert this patch since it's no longer a drop-in
replacement and the old, synchronous ProxyPass is reinstated.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] proxy_pass: possibly avoid breaking some middlewares
  2015-04-08 17:03   ` Eric Wong
@ 2015-04-08 17:23     ` Lin Jen-Shin (godfat)
  2015-04-08 17:32       ` Eric Wong
  0 siblings, 1 reply; 5+ messages in thread
From: Lin Jen-Shin (godfat) @ 2015-04-08 17:23 UTC (permalink / raw)
  To: Eric Wong; +Cc: yahns-public

On Thu, Apr 9, 2015 at 1:03 AM, Eric Wong <e@80x24.org> wrote:
> "Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
>> On Wed, Apr 8, 2015 at 5:34 AM, Eric Wong <e@80x24.org> wrote:
>> > +    # this probably breaks fewer middlewares than returning whatever else...
>> > +    [ 500, [], [] ]
>>
>> You probably meant [ 500, {}, [] ] here?
>
> No, arrays work fine, Rack headers just need to respond to #each
> with key + value strings.

I didn't know this, and just looked at the spec. Indeed it's only
claiming this. However some middleware bundled with Rack
would try to call [ ] method with a string, in those cases,
this would probably give a type error.

I think the spec should probably also claim that it should respond to
[ ] and taking strings as keys.

> I prefer Arrays since they use less memory per-entry, but here they're
> the same cost when empty.

That's great :P

> But I'm also likely to revert this patch since it's no longer a drop-in
> replacement and the old, synchronous ProxyPass is reinstated.

After playing a bit with hijack myself, I started to wonder if hijacking
is really a good idea, exactly the reason that it would probably break
a lot of middleware...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] proxy_pass: possibly avoid breaking some middlewares
  2015-04-08 17:23     ` Lin Jen-Shin (godfat)
@ 2015-04-08 17:32       ` Eric Wong
  0 siblings, 0 replies; 5+ messages in thread
From: Eric Wong @ 2015-04-08 17:32 UTC (permalink / raw)
  To: Lin Jen-Shin (godfat); +Cc: yahns-public

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> On Thu, Apr 9, 2015 at 1:03 AM, Eric Wong <e@80x24.org> wrote:
> > "Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> >> On Wed, Apr 8, 2015 at 5:34 AM, Eric Wong <e@80x24.org> wrote:
> >> > +    # this probably breaks fewer middlewares than returning whatever else...
> >> > +    [ 500, [], [] ]
> >>
> >> You probably meant [ 500, {}, [] ] here?
> >
> > No, arrays work fine, Rack headers just need to respond to #each
> > with key + value strings.
> 
> I didn't know this, and just looked at the spec. Indeed it's only
> claiming this. However some middleware bundled with Rack
> would try to call [ ] method with a string, in those cases,
> this would probably give a type error.

Right, I've fixed some Rack bugs like that in the past, and already
maintain a fair amount of Rack code which returns arrays.

> I think the spec should probably also claim that it should respond to
> [ ] and taking strings as keys.

I consider that too much, and Rack 1.x is pretty much set in stone
already.

> > But I'm also likely to revert this patch since it's no longer a drop-in
> > replacement and the old, synchronous ProxyPass is reinstated.
> 
> After playing a bit with hijack myself, I started to wonder if hijacking
> is really a good idea, exactly the reason that it would probably break
> a lot of middleware...

It's totally hackish, but acceptable in the absence of any other
standards.  It's still nice to be able to intercept requests (for
rewrites/redirects/etc) in middleware or use Rack::Cascade to
handle some requests directly in Rack while only hijacking only
a few.

I'll write up some documentation for Yahns::ProxyPass soon.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-04-08 17:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-07 21:34 [RFC] proxy_pass: possibly avoid breaking some middlewares Eric Wong
2015-04-08 10:38 ` Lin Jen-Shin (godfat)
2015-04-08 17:03   ` Eric Wong
2015-04-08 17:23     ` Lin Jen-Shin (godfat)
2015-04-08 17:32       ` Eric Wong

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).