Could someone explain this por favor ?
m.schonewille at economy-x-talk.com
Fri Aug 7 16:40:15 CEST 2015
Hi JBV and Mike,
On one occasion, I had a case where the carriage returns were converted
to crlf somewhere between the app and the php script. I have also had a
case where trailing cr's were added to the URL. This could cause the
decompress function to fail.
I would advice writing both encoded strings, the one produced by the
client and the one by the server, to a file and comparing them. Download
the file from the server with a good FTP programme.
Economy-x-Talk Consulting and Software Engineering
Installer Maker for LiveCode:
Buy my new book "Programming LiveCode for the Real Beginner"
LiveCode on Facebook:
On 8/7/2015 16:02, Mike Bonner wrote:
> No clue WHY it would react different, but the decompress error does seem to
> indicate the compressed data ends up "un-decompressable" (c)
> So yeah it does appear that either a) apache does something a bit different
> when the data comes in, or b) the urldecode on the server does things
> slightly different.
> You might ONLY urlencode, then return the data from the server straight
> (before decode) and a second copy after decode, and see if what you put in
> ends up as what you get out. (obviously, the data doesn't need to be
> decoded on the apache side, because it works.. But it'd be interesting to
> see what happens)
> On Fri, Aug 7, 2015 at 6:34 AM, <jbv at souslelogo.com> wrote:
>> When I run this simple test on my Mac (no client / server),
>> it works no matter how many successive "get URLdecode(it)"
>> lines :
>> get "the sky is blue"
>> get compress(it)
>> get base64encode(it)
>> get URLencode(it)
>> get URLdecode(it)
>> get URLdecode(it)
>> get base64decode(it)
>> get decompress(it)
>> put it
>> So, if Apache already does URLdecode in a POST request,
>> why does decompress throw an error ?
>> Could it be that the Apache URLdecode screws the content
>> of the string ?
>>> NVM, urlencode does indeed change the base64 encoded data, but still
>>> doesn't seem to be much point. Having said that, Mark is right. (Marks
>>> usually are)
>>> Since its the decompress that throws the error, (as I've just seen on my
>>> own test) it is looking like what goes in using urlencode, and what comes
>>> out, are not the same. Since, as Mark said, apache decodes when the data
>>> comes in, then its likely that the second urldecode (done by you, after
>>> server has done it once) munges things to the point where decompress
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode