Standard for X-Reproxy-Service?

[Brad Fitzpatrick]

David,

Perlbal already advertises its capabilities to downstream web servers.

- Brad


On Wed, 2 May 2007, David Weekly wrote:

> Brad,
>
> Helpful! It seems this header doesn't make a lot of sense for other
> reproxies, then.
>
> It seems to me that it could be helpful for a reverse proxy to be able
> to announce its capabilities to a downstream application server. That
> way an off-the-shelf install of a web service could take advantage of
> services like reproxying if available.
>
> (Or is that silly, since reproxy availability oughtn't be a "per
> connection" issue and therefore more properly belongs as an
> application server config setting?)
>
> Just a thought. Thanks again for the clarification.
>
> -David
>
>
> On 5/2/07, Brad Fitzpatrick <brad at danga.com> wrote:
> > David,
> >
> > [replying to the list, for others' edutainment]
> >
> > There are 3 things the backend webserver can instruct Perlbal to do in
> > its HTTP response headers, reproxy-wise:
> >
> > X-Reproxy-URL:  go serve a URL from elsewhere.  (actually a list of URLs,
> >    and Perlbal will find one that's alive)
> >
> > X-Reproxy-File:  go serve a file from the Perlbal machine's filesystem
> >
> > X-Reproxy-Service:  replay the request to a different named SERVICE in
> >     Perlbal's config file
> >
> >
> > That last one was designed for TypePad.com's migration (still in progress)
> > ... a request to TypePad.com first goes to Perlbal, then to a "redirector"
> > pool of HTTP servers, which looks at the request and decides, "Has this
> > user's account and/or this feature of the service been migrated to the new
> > architecture?  If so, X-Reproxy-Service: NEW_STACK, else
> > X-Reproxy-Service: OLD_STACK"  Or, the decider HTTP servers can just
> > return the new-stack contents or old-stack contents themselves.  In this
> > example, {NEW,OLD}_STACK are a Perlbal SERVICEs with their own
> > options/pool/etc.
> >
> > The reason TypePad couldn't just use X-Reproxy-URL, is because we didn't
> > want to pick a SPECIFIC URL (specific host) to internally redirect the
> > user... we still wanted Perlbal's smart load balancing to do that.  So
> > instead we just tell Perlbal to switch pools, and user gets back in line
> > for the fastest connection to another pool.  (which again may bounce them
> > around elsewhere with X-Reproxy-Whatever...)
> >
> > Hope that clarifies.
> >
> > - Brad
> >
> >
> > On Wed, 2 May 2007, David Weekly wrote:
> >
> > > Brad,
> > >
> > > Hi! Nate and I are both fans of the reproxying mechanism you baked
> > > into perlbal and have made a very rough alpha patch for pound to
> > > perform the same mechanism. It surprised me, however, to note the lack
> > > of clear documentation I was able to find on the definition of
> > > X-Reproxy-Service in particular.
> > >
> > > I think Nathan had read it as a way for a reverse proxy to announce to
> > > its downstream users its ability to reproxy, but in reading over the
> > > patches for perlbal / mogile, this doesn't seem to be the case. Could
> > > you point at us some better documentation for what, exactly, the
> > > header X-Reproxy-Service means?
> > >
> > > Cheers,
> > > -David
> > >
> > >
> >
>
>