I am all for this going in but I'm wondering why we have a thread on the list 
about it when we have a pretty good GitHub issue already?

Was there something that we need to discuss that's not in 
ticket/upcoming-pull-request?

On Feb 12, 2012, at February 12, 20127:06 PM, Charlie Robbins wrote:

> Yes. In reverse-proxying scenarios one must rewrite the incoming headers 
> before a second outbound request is made to the proxy target. Examples:
> 
> * `x-forwarded-*` headers 
> * https:// to http:// support often requires rewriting location headers.
> * wss:// to ws:// WebSocket support: must rewrite the x-websocket-origin 
> header (among others, don't have the spec off-hand)
> 
> In the two most popular current implementations:
> 
> * node-http-proxy: Reads the incoming headers off of the http.ServerRequest 
> object, modifies them, and then makes an outbound request to the reverse 
> proxy target via http.request
> * bouncy: Works behind a net.Server instance, but performs all HTTP header 
> parsing in pure Javascript to work around the lack of framing from the core 
> http-parser.
> 
> mmalecki has fixed this and should be opening pull requests tonight or 
> tomorrow. We'll be working on a new version of node-http-proxy which takes 
> advantage of them after they're merged. Personally I consider this more of a 
> bugfix than a feature.
> 
> --Charlie
> 
> On Sun, Feb 12, 2012 at 9:24 PM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> On Sun, Feb 12, 2012 at 23:50, Charlie Robbins
> <charlie.robb...@gmail.com> wrote:
> > All,
> >
> > I spoke with ry and substack about this issue when I was in San Francisco
> > last month: https://github.com/joyent/node/issues/2612. If I remember
> > correctly, it requires small changes to http-parser and the node wrapper. I
> > don't know this code base at all so I'm looking for someone to help
> > implement it.
> >
> > The purpose here is to make HTTP proxying much simpler. The proxy logic in
> > node-http-proxy right now is implemented through an http.Server instance.
> > This fix would allow it to be implemented through a net.Server instance
> > using this logic:
> >
> > 1. Create a net server.
> > (for each connection)
> > 2. Buffer chunks and execute them against an HTTPParser instance.
> > 3. Slice the HTTP headers from first one (or two) chunks, edit them, and
> > serialize them.
> > 4. Flush the buffer to the outgoing reverse proxy request.
> >
> > It is impossible to do (3) properly without this fix. I have a branch of
> > node-http-proxy which performs a naive slice looking for the first occurance
> > of `\r\n\r\n`.
> > https://github.com/nodejitsu/node-http-proxy/blob/experimental/lib/balancing-proxy.js#L257-261.
> > After some initial tests this approach is too naive and won't work in
> > production.
> >
> > Any help here would be fantastic.
> >
> > Thanks,
> > Charlie
> 
> I don't quite understand the issue. You want the total size of the HTTP 
> headers?
> 

Reply via email to