I have to use a caret (^) in a URL, but when I try it I get back the CURLE_URL_MALFORMAT error code (-3) and GetFailureReason() returns “No URL set!”. I thought I could just replace the caret with %5E, but the site I’m trying to connect to doesn’t seem to support that syntax. Any ideas?
I tried both Escape() and UrlEncode() and they both return the CURLE_COULDNT_RESOLVE_HOST error (-6) after the call to AsyncGetToString(). GetFailureReason() returns “Could not resolve host:” followed by the modified URL followed by the message “(Misformatted domain name)”. I don’t think either would work for me anyway since the site I’m trying to access doesn’t recognize % escapes, which is really annoying. I think I’m out of luck unless I can pass the caret through unmodified.
“TheEndless” wrote:
Is the ^ in a querystring value? If so, you might be able to post it as post data instead, depending on how liberal the code behind the site is…
Yes it is. I’ll give that a try. Thanks for the idea!
Edit: I couldn’t get it to work. I can’t be sure if it doesn’t accept the post or if I just haven’t figured out exactly what to post to exactly what url.
between that trick of flipping the authentication information between the http:// and the @ symbol (example above this) and using hex or octal or some other numbering system (not %), then you should be able to come up with some alternate encoding.
Since I’m guessing what you’re trying to do, (IN → function → OUT), I’m just taking a shot in the dark here.
Thanks. That was some interesting reading, but it doesn’t help my situation which is a query sent to a url like this: http://www.someplace.com/query/1.0?q=^parm
The site won’t accept the caret being replaced by %5E and the Roku box won’t send the caret.
Well, it doesn’t help you solve your problem, but it sounds like that web server is seriously nonconformant to web standards. According to RFC 1738, caret is an “unsafe character” and “All unsafe characters must always be encoded within a URL”. Caret is listed as unsafe because is it in a set of characters that “gateways and other transport agents are known to sometimes modify”. Again, this doesn’t help you unless you can use it to apply pressure to get that server made more compliant.
You’re right, it doesn’t help. :mrgreen: It’s not a big deal, but it would be nice if there was a way to just let anything be allowed in a URL and let the connection succeed or fail on it’s own.
The really funny thing is that it’s a Yahoo server. You’d think they’d get it right.
“renojim” wrote:
I guess you’d have to ask Yahoo. The caret is part of a query.
Yahoo may require a caret in the parameter name, but they almost definitely accept it URI encoded (it’s generally the web server’s responsibility to unescape, not the web-app). ^ is %5E escaped, if you want to test manually.
Make sure to encode only the parameter names and values in the string, not the full URL to post to, since it will see :, /, and = as values that need to be escaped. E.g.
The first thing I tried was to replace the caret, and only the caret, with %5E. It didn’t work. The parameter, which is one of several, was just ignored.
That’s odd. There doesn’t happen to be a test URL with a known response provided by yahoo, does there? That would make testing for the rest of us easier without revealing anything specific to your account there, if that mattes.