Connection header behavior not compliant with RFC2616

Created by: jcheng5

http://tools.ietf.org/html/rfc2616#section-14.10

The Connection general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections.
...
HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the
connection-token.

It looks to me like http-proxy currently passes along the Connection header value without parsing it. That might be OK assuming that the value will only ever be keep-alive or close, but it seems like it'd be better to follow the spec.

Currently, if the browser asks for keepalive, then the request to the target server will also use keepalive. This doesn't seem like very sensible default behavior to me; instead the browser-to-proxy keepalive policy should be totally independent from the proxy-to-target keepalive policy. In my project the browser might be connecting to the proxy via HTTPS over TCP, so we certainly want to use keepalive; but the proxy connects to the target servers using HTTP over domain sockets, so we don't want to use keepalive. Right now I can accomplish this by parsing and modifying the Connection header myself, but it seems more in the spirit of HTTP for the proxy to treat connection persistence as a hop-by-hop concept.

(Additionally, http://tools.ietf.org/html/rfc2616#section-13.5.1 indicates a number of headers that shouldn't be automatically forwarded by proxies: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding, and Upgrade.)