Could someone explain this por favor ?
bonnmike at gmail.com
Fri Aug 7 16:02:38 CEST 2015
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
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
> > the
> > server has done it once) munges things to the point where decompress
> > work.
> 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