[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Firewall question: WE GOT A LIVE ONE
James,
HTTPAPI already logs the data that it received. Changing your code to
call debug_msg() wouldn't tell me anything I don't already know. The
data looks like this (from your debug file):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN\" > <HTML>
<HEAD> <META
Also, HTTPAPI does not provide support for user applications calling
debug_msg(). debug_msg() is intended to be for use internally within
HTTPAPI -- it won't allow you to call it externally (unless you change
the code to allow it, of course.)
I hear you telling me that your response is always 28 characters. But
the above message is more than that, and it looks like an HTML document.
It could be coming from iPrism-httpd that Mike Krebs was talking about,
instead of your web service... If you received the whole message, you
might find out that it's an HTML document saying that the '400 is not
allowed to send out of the firewall. Just a guess... but certainly
possible, and would fit with Mike's assertion that it's a URL filtering
proxy.
James Lampert wrote:
> Scott Klement wrote:
>> The relevant error message is this one:
>>
>> SetError() #16: recvdoc: saveproc: Not all data was written!
>>
>> This means that HTTPAPI is calling a routine to save data to disk, and
>> the routine is telling HTTPAPI that it saved less data to disk than
>> HTTPAPI asked it to.
>
> Since our web service always replies with 28 bytes of data (not counting
> headers; i.e., 28 bytes to be processed by my "incoming()" callback
> routine), we know that anything longer than 28 bytes that "incoming()"
> is asked to process is, by definition, funky.
>
> How about if, should that happen, I do a debug_msg() from incoming(),
> with the first 256 bytes of the data we actually do get? Does that sound
> like it would tell us what we're actually getting (the next time we "get
> a live one")?
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------