"Lin Jen-Shin (godfat)" <god...@godfat.org> wrote:
> On Thu, Apr 9, 2015 at 1:03 AM, Eric Wong <e...@80x24.org> wrote:
> > "Lin Jen-Shin (godfat)" <god...@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.
