Could someone explain this por favor ?

Mark Schonewille 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.

--
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, <jbv at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list