> Is seems to be a failure in Curl_proxyCONNECT() for the connect of the data
> connection and I don't understand why and as I said previously I can't repeat
> the error.
>
> Any chance you can take this issue over to the curl-library list and try to
> debug the Curl_proxyCONNECT function? Adding a bunch of printfs or whatever
> could be a perfect start!

I'll gladly mail this to wherever you think is most appropriate but I'd like to avoid having to compile stuff myself here, that would lead me to far...

>>>> PS2: It's a different topic, but I would like to add I don't like the
>>>> dotdot removal 'feature'
>>
>>> Then you abuse URLs
>> Well I wouldn't really call it abuse, although it is a tad creative perhaps.
>> I prefer to see it as proper usage in a REST way of thinking.
>
>I'd say RFC3986 disagrees with you. But if you want this to for example get an
>option to get dotdot-removal switched off, I also suggest that you consider
>making a patch for it and arguing for why we want this in libcurl - on the
>curl-library list.

I'd say RFC 3986 is dated January 2005, whereas the thesis first detailing REST was written in 2000. A very simple use case would be passing in path variables into a webservice (i.e. www.server.com/servicebot/copy/localfiles/<path>). But I don't really want to get into the middle of this kind of discussion, my paycheck isn't high enough. Regarding making a patch for it : I'd love to but there's only so many projects I can handle, if I have to get into the code for this app too it's going to take way too much of my time (see previous answer). I guess I could think of a million sensible looking URLs where ".." isn't interpreted as part of the path but if the big guys like Tim Berners Lee, Apache, Google, etc... decide otherwise there's no point in putting up a fight by submitting patches everywhere. Guess I'll have to map dotdot to something else or choose a different character or whatever dumb workaround. In my humble opinion the interpretation of everything after server.com/ should be left up to the webservi
ce receiving it. Rather than shoehorning every possible service into a hierarchical filesystem imitation with the same limitations they had in 1980, I would leave that part of the URL interpretation up to the service that uses it. Especially because that RFC claims to speak for every possible protocol. Just my two cents.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-09-13