> 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/ba...
>> .
>> > 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?
