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.
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553
Installer Maker for LiveCode:
http://qery.us/468
Buy my new book "Programming LiveCode for the Real Beginner"
http://qery.us/3fi
LiveCode on Facebook:
https://www.facebook.com/groups/runrev/
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, <j...@souslelogo.com> wrote:
Mike,
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 ?
jbv
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
the
server has done it once) munges things to the point where decompress
can't
work.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
