No, INetLibURLCrack will not properly handle all URLs, especially URLs with
URL encoded vars at the end. One work around would be to use a post instead
of a get. The URL http://123.123.123.123/a should not confuse URLCrack.
The arguments u=whoever&p=pass&m=1&n=1 would be passed as extra data in your
INetLibSockHTTPReqSend call. Regardless of what you set the verb to, this
will result in a url encoded post.
Or, you could just ignore the error. INetLibURLCrack typically reads past
the end of the block, but it does not appear to write past the end of an
allocated block. Presumably, at least some PQA exhibit this problem. I
have always avoided it, but it is probably pretty harmless.
-jjf
-----Original Message-----
From: Chris DiPierro [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 18, 2000 8:02 AM
To: Fitzpatrick, Joe
Cc: '[EMAIL PROTECTED] '
Subject: RE: INetLibOpen Problems (Causes direct mem accesses)
Hrm...ok, well http://123.123.123.123/ was a white lie in that it's much
simpler than the real URL, but I didn't realize that INetLibURLCrack was
so weak...
I'm really doing things like:
http://123.123.123.123/a?u=whoever&p=pass&m=1&n=2 ... etc etc ...
Can INetLib not always successfully handle this?!?!
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
