I think you said you are now using postargs, not pastargarray. And I think you are on 5.0. Therefore you'll need to set encoding=url on the variable you call in postargs, since the default encoding of html will corrupt your post arg string. How's that sound? Robert
-----Original Message----- From: William M Conlon [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 1:39 PM To: [email protected] Subject: Re: Witango-Talk: bug in <@URL> with null POST arguments? I decided to use ethereal to capture packets. never used it before, but WOW. Anyway, on to the actual problem, which appears to be related to encoding of the arguments. Here's a snip from the post from paypal: address_country=United+States&address_city=Palo+Alto ... &payer_email=bill%40tothept.com& Here's a snip from the post back to paypal address_city=Palo%20Alto&address_country=United%20States ... &payer_email=bill%40tothept%2Ecom& A few things to note: 1. argument order is shuffled by witango as it loads the POSTARG_array alphabetically (which is the order it writes out the POST args in the log file, BTW). 2. witango is converting the '+' to a space when decoding the arguments ('Palo+Alto' ==> 'Palo Alto') 3. paypal is only URL encoding the '@', ignoring '.', ' ', and who know what else Someone please tell me I'm mistaken and this isn't as fouled up as it looks right now. Bill On Mar 13, 2006, at 4:40 PM, Scott Cadillac wrote: > Hi Bill, > > Try http://www.httpsniffer.com > > Hope that helps. > > > Scott Cadillac, > Email: [EMAIL PROTECTED] > http://scott.cadillac.bz > > >> -----Original Message----- >> From: William M Conlon [mailto:[EMAIL PROTECTED] >> Sent: Monday, March 13, 2006 5:31 PM >> To: [email protected] >> Subject: Re: Witango-Talk: bug in <@URL> with null POST arguments? >> >> Thanks, using POSTARGS instead of POSTARGARRAY allows me to include >> the NULL variable. >> >> But I'm still getting an INVALID response from my post-back to >> paypal. >> >> As mentioned, I am testing by doing the postback to both paypal and >> my own witango server so I can inspect the POSTARGs in the witango >> log. The POSTARGs are identical -- I can cut and paste into a text >> editor and they match exactly. >> >> But ... The length of the POSTARGs is different. So there must be >> some non-printing characters that witango is stripping. Next up is >> to get a hex dump of the two posts so I can compare. I don't really >> know how to do this in Witango, so I'm about to write some Perl, >> unless someone has an HTTP Post dumper available. >> >> Bill >> On Mar 11, 2006, at 7:20 AM, Robert Shubert wrote: >> >>> I bumped into this the other day in 5.5. I haven't had a chance to >>> build a >>> test case and report it. You should be able to pass null value >>> postargs, but >>> Witango doesn't seem to keep the pairs with null values. >>> >>> I believe the work around would be to not use the postargarray >>> attribute, >>> but to use postargs= which allows you to simply build a >> text string >>> a la >>> name1=value1&name2=value2 and simply send it with the request. >>> >>>> From the docs: >>> / >>> The optional POSTARGS attribute specifies the post content for the >>> request, >>> for example, a list of name-value pairs. They may not be specified >>> with an >>> array variable; to specify post arguments with an array, use the >>> POSTARGARRAY attribute. >>> >>> The names and values must be separated with = (equal sign) >>> characters, and >>> name-value pairs must be separated with & (ampersand) characters. >>> Additionally, the names and values must be encoded. You may >> perform >>> this >>> encoding using the <@URLENCODE> meta tag: Witango does not >>> automatically >>> encode data passed in the POSTARGS attribute. >>> >>> The optional POSTARGARRAY attribute is used to specify post >> arguments >>> (name-value pairs) with an array. The value of POSTARGARRAY is the >>> name of a >>> variable containing an array of exactly two columns: the first >>> column of the >>> array must contain the names, and the second column must contain >>> the values. >>> Witango extracts these from the array and uses them in the HTTP >>> request. If >>> an array of more than two columns is referenced, an error >> is returned. >>> >>> When the POSTARGS or POSTARGARRAY attribute is present, the >> type of >>> HTTP >>> request issued by the <@URL> meta tag changes to POST from GET. >>> / >>> >>> You can also work around this problem by always having a value, if >>> possible, >>> usually some default is available to use. >>> >>> Robert >>> >>> -----Original Message----- >>> From: William M Conlon [mailto:[EMAIL PROTECTED] >>> Sent: Friday, March 10, 2006 10:39 PM >>> To: Witango-Talk >>> Subject: Witango-Talk: bug in <@URL> with null POST arguments? >>> >>> I'm having a hard time getting Paypal Instant Payment >> Notification to >>> validate. >>> >>> The process requires me to post-back to Paypal the same data that >>> they posted to me. I'm using Bryan Hughes' paypal_notify.taf as a >>> prototype, but I can't get Paypal to respond to my POST-back with a >>> 'Verified' answer. I always get an 'Invalid' answer. >>> >>> I've investigate by running the same post-back to paypal and to my >>> witango server. This shows that there is indeed a difference in the >>> POST arguments! Apparently witango 5.0.1.065 <@URL> is not POSTING >>> an argument with a NULL value. So where Paypal sends me >>> >>> <snip> >>> charset=windows-1252 >>> custom= >>> first_name=William >>> </snip> >>> >>> Witango posts back: >>> <snip> >>> charset=windows-1252 >>> first_name=William >>> </snip> >>> >>> The debug trace shows that the custom variable is indeed in the post >>> argument array: >>> 10/03/2006 19:17:04 66.135.197.164 >>> [EMAIL PROTECTED] -1470862416 1 >>> 97 [Changed Vars] request$postarg_array[11,1]=custom; >>> request$postarg_array[11,2]=; >>> >>> Has anyone resolved this? >>> >>> Do I have to generate the entire HTTP post myself instead of using >>> <@URL>? >>> >>> >>> Bill >>> >>> >> ______________________________________________________________ >> ________ >>> __ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>> >> ______________________________________________________________ >> ________ >>> __ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> Bill >> >> William M. Conlon, P.E., Ph.D. >> To the Point >> 345 California Avenue Suite 2 >> Palo Alto, CA 94306 >> vox: 650.327.2175 (direct) >> fax: 650.329.8335 >> mobile: 650.906.9929 >> e-mail: mailto:[EMAIL PROTECTED] >> web: http://www.tothept.com >> >> ______________________________________________________________ >> __________ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> > > > ______________________________________________________________________ > __ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf Bill William M. Conlon, P.E., Ph.D. To the Point 345 California Avenue Suite 2 Palo Alto, CA 94306 vox: 650.327.2175 (direct) fax: 650.329.8335 mobile: 650.906.9929 e-mail: mailto:[EMAIL PROTECTED] web: http://www.tothept.com ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
