NYCPHP Meetup

[Jayesh Sheth]

Hi all,

I have only been scanning this list on some days, so I hope no one has 
mentioned this yet.

I was planning to buy HTTP Interceptor from Siliconwold:
http://www.siliconwold.com/

I tried it out and it seemed quite good. I need it when I was madly 
debugging an issue where my XUL Fortune Cookie thing was not working on 
very recent versions of PHP 4.3.x ( greater than 4.3.4, I think). (I 
eventually figured out with the help of this program that the issue 
seems to lie with a newer version of the PEAR XML-RPC library which is 
bundled with PHP 4.3.4+. This version does not "play nice" with the 
JavaScript client XML-RPC library. I have a brief write-up on that here, 
in case any one is interested: http://moztips.com/index.php?id=360 . I 
planned to put together a detailed debugging tutorial with a conclusion 
stating where the problem lay; I gathered all the necessary scraps of 
information, but my brain bluescreened before I finished putting those 
scraps together. For those of you still waiting for the source from my 
NYPHP presentation: I have not forgotten, and sorry for the delay. I 
will publish a document on why this incompatibility issue is occuring, 
and steps to resolve it - which I still have to work out myself.)

In any case, I should conclude with this statement:
I wanted to write my own proxy thing, and I plan to take a look at Chris 
Shiflett's Protoscope script. In the mean time, I might just buy HTTP 
Interceptor, so that I have something to work with before my own thing 
is ready.

I should also state that I tried another shareware program which worked 
differently from HTTP Interceptor. You have to configure HTTP 
Interceptor as a proxy HTTP server in your browser. This other program 
tried to automatically monitor and log all HTTP traffic by hooking into 
what Windows was receiving and sending. I do not find this system to be 
good; I should also mention, that this other program torpedoed my 
computer, and I had to resort to a safe-mode rescue attempt to bring it 
back to a working state.

(I keep trying to end this email, but then I think of more things I want 
to say ...)

In debugging web services programs, I found this techique to be useful. 
Suppose I am posting to a remote PHP script which acts as an XML-RPC 
server. I want to monitor what it is sending back to the XML-RPC client. 
I do the following: I use print_r() or var_dump() or echo to output an 
array or variable's contents, then I use PHP's output buffering to save 
that outputted debug info to another array or variable. Then I use 
PEAR's excellent logging library ( http://pear.php.net/package/Log ) to 
save that info to a log file. Then I use the client to communicate with 
the server, and look at the log file to see what the server tried to 
communicate back.

I hope that all made sense.

Best Regards,
- Jay