Frans,
>>> It's an page request that generates a 301 status. HttpAsy is not a
>>> threaded application, seems there the same url will then not
>>> generate a problem. HttpThr1 doesn't do a async call so again no
>>> problem.
>>
>> There should be no difference between running the component in th
It's an page request that generates a 301 status. HttpAsy is not a
threaded application, seems there the same url will then not generate
a problem. HttpThr1 doesn't do a async call so again no problem.
There should be no difference between running the component in the
context of a worker thread
Frans van Daalen wrote:
>> Hi,
>>
>> thanks for the report.
>>
>>> Sorry to inform you that the problem is still there. Even when not
>>> behind a
>>> proxy the GetAsync will fired the requestdone even when not ready
>>> causing the next call to generate an exception "HTTP component is
>>> busy"
Hi,
thanks for the report.
Sorry to inform you that the problem is still there. Even when not behind
a
proxy the GetAsync will fired the requestdone even when not ready causing
the next call to generate an exception "HTTP component is busy"
Are you able to reproduce the issue with OverbyteH
ICS support mailing"
Sent: Monday, March 28, 2011 5:01 PM
Subject: Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
>>> Arno Garrels wrote:
>>>> Frans van Daalen wrote:
>>>>>>> One was using webmarshal and the other ISA. But i'
Arno Garrels wrote:
Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the "HTTP component is busy"
error message when using the async get.
It still doesn't work probably so don't send it to your customer
yet. I'm workin
Arno Garrels wrote:
Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the "HTTP component is busy"
error message when using the async get.
It still doesn't work probably so don't send it to your customer
yet. I'm workin
Arno Garrels wrote:
> Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the "HTTP component is busy"
error message when using the async get.
>>>
>>> It still doesn't work probably so don't send it to your cus
Frans van Daalen wrote:
>>> One was using webmarshal and the other ISA. But i'm not behind a
>>> proxy and also still keep getting the "HTTP component is busy"
>>> error message when using the async get.
>>
>> It still doesn't work probably so don't send it to your customer yet.
>> I'm working o
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the "HTTP component is busy" error
message when using the async get.
It still doesn't work probably so don't send it to your customer yet.
I'm working on this stuff again since a couple of hours
Frans van Daalen wrote:
>> What proxy server does your client use?
>
> One was using webmarshal and the other ISA. But i'm not behind a
> proxy and also still keep getting the "HTTP component is busy" error
> message when using the async get.
It still doesn't work probably so don't send it to y
What proxy server does your client use?
One was using webmarshal and the other ISA. But i'm not behind a proxy and
also still keep getting the "HTTP component is busy" error message when
using the async get.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Frans van Daalen wrote:
>> That's not all, I found and fixed some more problems so far.
>> I just checked in Rev. #670 into SVN, please test the fix
>> and report back as soon as possible, thanks for your help.
>>
>> Log:
>> Proxy authentication with relocations (hopefully) fixed. SSL not
>> teste
That's not all, I found and fixed some more problems so far.
I just checked in Rev. #670 into SVN, please test the fix
and report back as soon as possible, thanks for your help.
Log:
Proxy authentication with relocations (hopefully) fixed. SSL not tested
yet.
If it still doesn't work it's prob
Arno Garrels wrote:
> Arno Garrels wrote:
>> Frans van Daalen wrote:
> Update : Seems there are still scenario's where the problem
> returns also sometimes the proxy settings are lost creating a 407
> when a relocation happens. Seems to happen when executing a
> GetAsync and a reloc
Arno Garrels wrote:
> Frans van Daalen wrote:
Update : Seems there are still scenario's where the problem returns
also sometimes the proxy settings are lost creating a 407 when a
relocation happens. Seems to happen when executing a GetAsync and a
relocate is triggered (with foll
Tracing and debugging is a problem when there's not much on the call
stack as with the THttpCli where many events are triggered by posting
messages instead of calling event handlers directly.
Just a side note: Posting a message and calling event handlers directly have
totally different behaviou
Frans van Daalen wrote:
>>> Update : Seems there are still scenario's where the problem returns
>>> also sometimes the proxy settings are lost creating a 407 when a
>>> relocation happens. Seems to happen when executing a GetAsync and a
>>> relocate is triggered (with follow relocation set)
>>
>>
Update : Seems there are still scenario's where the problem returns
also sometimes the proxy settings are lost creating a 407 when a
relocation happens. Seems to happen when executing a GetAsync and a
relocate is triggered (with follow relocation set)
Thanks for the report. That's probably becau
Frans van Daalen wrote:
You are right, I did not test the GetAsync, in async mode
RequestDone is actually fired with StatusCode 0 after relocation.
Triggered by a call to CheckDelaySetReady in GetBodyLineNext.
>>>
>>> When I add a check for FLocationFlag there it _SEEMS_ to fi
You are right, I did not test the GetAsync, in async mode
RequestDone is actually fired with StatusCode 0 after relocation.
Triggered by a call to CheckDelaySetReady in GetBodyLineNext.
When I add a check for FLocationFlag there it _SEEMS_ to fix it,
has to be still tested very hard in order n
You are right, I did not test the GetAsync, in async mode
RequestDone is actually fired with StatusCode 0 after relocation.
Triggered by a call to CheckDelaySetReady in GetBodyLineNext.
When I add a check for FLocationFlag there it _SEEMS_ to fix it,
has to be still tested very hard in order n
What will happen if we want no-follow-relocation and just need to pump the
301/302/307 headers?
Regards,
SZ
On Fri, Dec 24, 2010 at 3:37 PM, Arno Garrels wrote:
> Arno Garrels wrote:
> > Arno Garrels wrote:
> >> Frans van Daalen wrote:
> Frans van Daalen wrote:
> > seems that the bug
Arno Garrels wrote:
> Arno Garrels wrote:
>> Frans van Daalen wrote:
Frans van Daalen wrote:
> seems that the bug is also somewhere related to the NTLM code or
> call because the icslogger shows the following
>
> - Starting relocation process
> - state = httpReady
> -
Arno Garrels wrote:
> Frans van Daalen wrote:
>>> Frans van Daalen wrote:
seems that the bug is also somewhere related to the NTLM code or
call because the icslogger shows the following
- Starting relocation process
- state = httpReady
- PrepareNTLM
- Prepare
Frans van Daalen wrote:
>> Frans van Daalen wrote:
>>> seems that the bug is also somewhere related to the NTLM code or
>>> call because the icslogger shows the following
>>>
>>> - Starting relocation process
>>> - state = httpReady
>>> - PrepareNTLM
>>> - PrepareNTLM
>>> - RequestDone
Frans van Daalen wrote:
seems that the bug is also somewhere related to the NTLM code or call
because the icslogger shows the following
- Starting relocation process
- state = httpReady
- PrepareNTLM
- PrepareNTLM
- RequestDone
Frans van Daalen wrote:
>
> Found an error in OverbyeIcsHttpProt, not the reason for the error
> above
>
> line 1760 :
> DebugLog(loProtSpecDump, Format('PrepareNTLMAuth end, FStatusCode =
> %d ' +
>
> should be
>
> DebugLog(loProtSpecDump, Format('PrepareNTLMAuth Begin, FStatusCode =
> %d '
Frans van Daalen wrote:
> seems that the bug is also somewhere related to the NTLM code or call
> because the icslogger shows the following
>
> - Starting relocation process
> - state = httpReady
> - PrepareNTLM
> - PrepareNTLM
> - RequestDone
Forgot to say that the logged status after the call is almost always
HttpDnsLookup
and that the exact line in HttpRequestDone is
If (Sender as ThttpCli).State in [httpReady,httpAborting,httpClosing]
then
Begin
PostMessage((Sender as THttpCli).CtrlSocket.Handle, WM_QUIT, 0, 0);
I
30 matches
Mail list logo
