Do you need to set the json content-type headers in the HTTPService requests?
BTW, the flash player doesn't support delete or put, will that be a problem for you? -Sam On Mon, May 18, 2009 at 1:35 PM, Kai Griffin <[email protected]> wrote: > On 18/05/2009 21:54, Rhett Sutphin wrote: >> >> Hi Kai, >> >> On May 18, 2009, at 2:40 PM, Kai Griffin wrote: >> >>> Hi Brian, >>> >>> I've been escaping the square brackets and double quotes in curl, like >>> this \[\" ....\" \] - which seems to work. I'll start using -g in curl so >>> I don't have to escape the square braces. >>> >>> Wrapping the url in single quotes results in the single quote being >>> interpreted as part of the url itself, and curl complains that "protocol >>> 'http is not supported". >>> >>> As for %22's... I cannot make that work at all. If I encode double >>> quotes as %22's in curl, couchdb complains about invalid JSON, and it looks >>> as if all the %'s have been stripped out and the 22's become part of the >>> request. For example the following request: >>> >>> (snip) >> >> You are on windows, right? In the regular windows shell, environment >> variable substitution is done with %ENV_VAR_NAME% (roughly equivalent to >> $ENV_VAR_NAME in bash). So %22SYD%22 would mean "take the value of the >> 22SYD environment variable and concatenate 22". If there is no such env >> var, the result would just be "22". This fits with the invalid JSON couchdb >> is seeing. >> >> Long story short, I think you need to escape the '%'s from the windows >> shell. I don't know how to do this, but I'm sure it is possible. > > Aha! Thank-you, Rhett - this never crossed my mind, though it makes perfect > sense. It's a simple matter of doubling the % (%%) to ensure the command > processor doesn't try to do the replacement. When I just tried this, my > curl command worked fine, and as Brian suggested, I get a successful result > whether I escape the quotes with backslashes or encoded them as %22's. Now > I just need to figure out why the HTTPService from Flex is not working... > clearly the url-encoding has nothing to do with it and I've no doubt got an > unrelated bug in my own work. > > Best regards, > Kai > > >> >> Rhett >> > >
