curl-library
Re: [PATCH] CURLOPT_PROXYHEADER: send/replace proxy headers only
Date: Fri, 24 Jan 2014 00:49:06 +0100
On Thu, Jan 23, 2014 at 11:56:43PM +0100, Daniel Stenberg wrote:
> I think this is a tricky question and I'd love to get more feedback
> on this. The existing (before this patch) features affect headers to
> both the server and the proxy, and since it does that we can't really
> know which of the features existing applications want to preserve for
> the future.
>
> A - they add/remove/change headers for the origin server so the proxy should
> not get them. Like server auth or cookies.
>
> B - they add/remove/change headers for the proxy, so the server should not
> get them. Like proxy auth or similar
>
> C - they add/remove/change headers for _both_ the proxy and the server. Like
> user-agent or similar.
>
> You're clearly focusing on case (A) and I suppose we have reason to
> suspect that is the most common use case. Is that a valid reason for
> us to say that (B) and (C) applications need to be modified for them
> to do right in the release with this change? I'm hesitating. Perhaps
> it is.
IMHO, it would be a pretty major break to change the default behaviour. There
are undoubtedly applications out there that fall into all three categories, and
a change would break at least one category. Yes, the current behaviour is
unclear and can cause security issues (in applications that that aren't aware
of the behaviour), but it does work in most situations since servers will
mostly ignore headers that aren't meant for them.
What about keeping the current behaviour as-is by default; i.e. if a header is
set (with the old option), it is sent to both proxy server and destination
server. But if the new option is set, the behaviour changes, such that headers
set with the new option are only sent to the proxy and headers set with the
old option are sent only to the destination server. Setting the new option to
NULL enables the new behaviour but without sending any headers to the proxy
server.
That provides for backward compatibility as well as allowing all use cases.
>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-01-24