Daniel and Dan, thanks for your comments. Dan: > 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.
I agree. Thinking aloud, perhaps the best solution would be to keep backward-compatible behavior as currently implemented in Vijay's patch, but issue a warning (especially in verbose mode). As I see it, the choice is: 1. Break backward compatibility. The compatibility is with a problematic and potentially unsafe behavior, but it is a backward compatibility nonetheless. One can imagine that --header is used only to set user agent, in which case there is nothing wrong sending it to both proxy and origin. There are likely applications that do it and that depend on it. (By the way, even with Vijay's patch, --user-agent is always carried to both header sets, while --referer is never sent to the proxy. Of course these can be overridden by --header and --proxy-header.) 2. Keep behavior that is not only unsafe, but also default and accepted silently. It doesn't take much to imagine a user who develops and tests an application that uses curl to open a direct https connection with some sensitive data in --header. Satisfied that the application works well and securely, the user adds --proxy option, perhaps because the application needs to be deployed in an environment where proxy is required. User tests the application again and finds that it does what it should, and so considers his/her work done. The user reasonably expects that curl would know how to tunnel the request through the proxy in a secure manner, and does not devote his/her time to try to find security holes in curl. (Obviously, I was not that user!) The moral is - if that behavior has to be unsafe and default, at least it shouldn't be silent. > 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. I think that this argument is for the opposing point of view, i.e. for changing current behavior, rather than keeping it. We are talking here about a security issue in the context where security matters. Yes, curl currently does work - in a way that if proxy server or any party between client and proxy does not eavesdrop, then we will be fine. But with such an approach to security we can as well forget about SSL altogether, send an unencrypted request, proxy it by GET, and avoid the whole problem of two header sets that we discuss here. That's why I am suggesting a warning, to let the user know that there is a potential issue and how to fix it. Daniel: > It could also be a reason to reconsider the name. Perhaps a different one > would > make it clearer to users what the option actually does? I would assume that a > typical user won't really see the difference when switching from http:// to > https:// > or vice versa. I thought about it too. "connect-header" would probably be too confusing by not adequately describing its purpose (what connection are we talking about?) Perhaps "proxy-connect-header"? We are talking here about stuff for advanced users, so long and unfriendly name would probably be ok. Anyway, I'll take any name, as long as the option is there. Thanks Maciej On Thu, Jan 23, 2014 at 5:49 PM, Dan Fandrich <d...@coneharvesters.com> wrote: > 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 ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
