Hi -
> > I guess I don't see a problem here. HTTP request headers are by > > definition optional things. How it's used --- why would we want to > > dictate "only ... for" anything? We do what we do. > > But what we do is technically just pass the given string to curl as is. > It is just that I know what people will do is read the source code and > read the CURLOPT_HTTPHEADER documentation and think they can just use > it like that. [...] > Except that people will figure out what it really does. But documentation would do nothing to dissuade such people! If we have to change away from libcurl, they'll just read the new code too. If they need these funky header manipulations anyway, they'll just change OUR code. > I don't think it is a scare story to explicitly say: "Note that the > current implementation uses libcurl, but you shouldn't rely on that > fact. The only supported usage of this method is for adding an > optional header which might or might not be passed through to the > server." OK, please feel free to add any such text that makes you feel more comfortable. > Sure. It is simple to write your own client code using libcurl if you > want to. And it might be too hard to sanity check the input. If it is, > too bad. But if it is easy to check then I think we should simply do > that to catch user mistakes. We were talking about people who read the code to work around the documented pattern. These would not be user mistakes. We're proposing protecting someone not from their mistakes, but their deliberate reverse-engineering. - FChE
