Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 have this code
HttpClient.OnRequestDone := HttpRequestDone;
HttpClient.OnCommand := HttpClientCommand;
HttpClient.OnLocationChange := HttpClientRelocate;
httpclient.GetASync;
httpclient.CtrlSocket.MessageLoop
in HttpRequestDone i have the following code
PostMessage((Sender as THttpCli).CtrlSocket.Handle, WM_QUIT, 0, 0);
///
Sometimes when I check the status after the GetAsync with this code
if HttpClient.State <> httpready
then LogEvent('Execute','After
MakeTheCall',StateToStr(HttpClient.State),HttpClient.Url);
I find several entries in the log event, but I have trouble
understanding. Can someone give me a hint
As far as I can find the problems begin when the call gets a 302 and in
this case the 302 will relocate from www. to www2.xxx
Tested both in V6 and V7
Frans
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 ' +
seems like a copy past errror.
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
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 > - RequestDonethere?? > It will trigger the onRequestDone That is intended in case of SetReady was called in StartRelocation or LocationSessionClosed because LocationChangeMaxCount reached the limit. > but at the same time the > relocation is still going on because this is the rest of the ics log > while I also get the trace from my own software due to the trigger. > > - Login www2.xxx > - State = httpDnsLookup No idea, sorry. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 ' +
>
>
>
> seems like a copy past errror.
>
You do not use latest ICSv7 since the line number actually is 1800,
nevertheless it's a typo of course.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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>> there?? >>> It will trigger the onRequestDone >> >> That is intended in case of SetReady was called in StartRelocation or >> LocationSessionClosed because LocationChangeMaxCount reached the >> limit. >> > > It did not reached its locationmaxcount. I think it it a SetReady from > > procedure THttpCli.StateChange(NewState : THttpState); > > line 1478 > >if PrepareNTLMAuth(FlgClean) or >{$IFDEF UseDigestAuthentication} >PrepareDigestAuth(FlgClean) or >{$ENDIF} >PrepareBasicAuth(FlgClean) then begin > >else > line 1534 >TriggerRequestDone; * > > - > But I have trouble tracing the exact moment the ready is set. That's quite easy, set breakpoints in StartRelocation and LocationSessionClosed. Test URL www.microsoft.com, it works for me with current ICSv7 from the wiki: http://wiki.overbyte.be/wiki/index.php/ICS_Download > > Question : Before we re-enter login should we not set the state to > htttpNotConnected when moving from www.xxx to www2.xxx ? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 - PrepareNTLM - RequestDone>> >>> That is intended in case of SetReady was called in StartRelocation >>> or LocationSessionClosed because LocationChangeMaxCount reached the >>> limit. >>> >> >> It did not reached its locationmaxcount. I think it it a SetReady >> from >> >> procedure THttpCli.StateChange(NewState : THttpState); >> >> line 1478 >> >>if PrepareNTLMAuth(FlgClean) or >>{$IFDEF UseDigestAuthentication} >>PrepareDigestAuth(FlgClean) or >>{$ENDIF} >>PrepareBasicAuth(FlgClean) then begin >> >>else >> line 1534 >>TriggerRequestDone; * >> >> - >> But I have trouble tracing the exact moment the ready is set. > > That's quite easy, set breakpoints in StartRelocation and > LocationSessionClosed. Test URL www.microsoft.com, it works for me > with current ICSv7 from the wiki: > http://wiki.overbyte.be/wiki/index.php/ICS_Download 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. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 > - PrepareNTLM > - PrepareNTLM > - RequestDonethere?? > It will trigger the onRequestDone That is intended in case of SetReady was called in StartRelocation or LocationSessionClosed because LocationChangeMaxCount reached the limit. >>> >>> It did not reached its locationmaxcount. I think it it a SetReady >>> from >>> >>> procedure THttpCli.StateChange(NewState : THttpState); >>> >>> line 1478 >>> >>>if PrepareNTLMAuth(FlgClean) or >>>{$IFDEF UseDigestAuthentication} >>>PrepareDigestAuth(FlgClean) or >>>{$ENDIF} >>>PrepareBasicAuth(FlgClean) then begin >>> >>>else >>> line 1534 >>>TriggerRequestDone; * >>> >>> - >>> But I have trouble tracing the exact moment the ready is set. >> >> That's quite easy, set breakpoints in StartRelocation and >> LocationSessionClosed. Test URL www.microsoft.com, it works for me >> with current ICSv7 from the wiki: >> http://wiki.overbyte.be/wiki/index.php/ICS_Download > > 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 not to introduce new bugs: TriggerDocEnd; if {(FResponseVer = '1.0') or (FRequestVer = '1.0') or } { see above} { [rawbite 31.08.2004 Connection controll] } (FCloseReq) then { SAE 01/06/04 } FCtrlSocket.CloseDelayed else if not FLocationFlag then // <== Try this change and test, test, test... CheckDelaySetReady; { 09/26/08 ML } -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 is also somewhere related to the NTLM code or > > call because the icslogger shows the following > > > > - Starting relocation process > > - state = httpReady > > - PrepareNTLM > > - PrepareNTLM > > - RequestDone> there?? > > It will trigger the onRequestDone > > That is intended in case of SetReady was called in StartRelocation > or LocationSessionClosed because LocationChangeMaxCount reached the > limit. > > >>> > >>> It did not reached its locationmaxcount. I think it it a SetReady > >>> from > >>> > >>> procedure THttpCli.StateChange(NewState : THttpState); > >>> > >>> line 1478 > >>> > >>>if PrepareNTLMAuth(FlgClean) or > >>>{$IFDEF UseDigestAuthentication} > >>>PrepareDigestAuth(FlgClean) or > >>>{$ENDIF} > >>>PrepareBasicAuth(FlgClean) then begin > >>> > >>>else > >>> line 1534 > >>>TriggerRequestDone; * > >>> > >>> - > >>> But I have trouble tracing the exact moment the ready is set. > >> > >> That's quite easy, set breakpoints in StartRelocation and > >> LocationSessionClosed. Test URL www.microsoft.com, it works for me > >> with current ICSv7 from the wiki: > >> http://wiki.overbyte.be/wiki/index.php/ICS_Download > > > > 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 not to introduce new bugs: > >TriggerDocEnd; >if {(FResponseVer = '1.0') or (FRequestVer = '1.0') or } >{ see above} >{ [rawbite 31.08.2004 Connection controll] } >(FCloseReq) then { SAE 01/06/04 } >FCtrlSocket.CloseDelayed >else if not FLocationFlag then // <== Try this change and test, > test, test... >CheckDelaySetReady; { 09/26/08 ML } > > -- > Arno Garrels > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 not to introduce new bugs:
TriggerDocEnd;
if {(FResponseVer = '1.0') or (FRequestVer = '1.0') or }
{ see above}
{ [rawbite 31.08.2004 Connection controll] }
(FCloseReq) then { SAE 01/06/04 }
FCtrlSocket.CloseDelayed
else if not FLocationFlag then // <== Try this change and test,
test, test...
CheckDelaySetReady; { 09/26/08 ML }
I tested it and it seems indeed to solve the problem. I spend several hours
extra trying to read and understand the reason behind this but httprot file
is not that easy to read :-)
Well done and thank you!
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 not to introduce new bugs:
TriggerDocEnd;
if {(FResponseVer = '1.0') or (FRequestVer = '1.0') or }
{ see above}
{ [rawbite 31.08.2004 Connection controll] }
(FCloseReq) then { SAE 01/06/04 }
FCtrlSocket.CloseDelayed
else if not FLocationFlag then // <== Try this change and
test, test, test...
CheckDelaySetReady; { 09/26/08 ML }
I tested it and it seems indeed to solve the problem. I spend several
hours extra trying to read and understand the reason behind this but
httprot file is not that easy to read :-)
Well done and thank you!
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)
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 fix it,
>>> has to be still tested very hard in order not to introduce new bugs:
>>>
>>>TriggerDocEnd;
>>>if {(FResponseVer = '1.0') or (FRequestVer = '1.0') or }
>>>{ see above}
>>>{ [rawbite 31.08.2004 Connection controll] }
>>>(FCloseReq) then { SAE 01/06/04 }
>>>FCtrlSocket.CloseDelayed
>>>else if not FLocationFlag then // <== Try this change and
>>> test, test, test...
>>>CheckDelaySetReady; { 09/26/08 ML }
>>>
>>
>> I tested it and it seems indeed to solve the problem. I spend several
>> hours extra trying to read and understand the reason behind this but
>> httprot file is not that easy to read :-)
>>
>> Well done and thank you!
>
> 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 because SetReady is skipped with
it's code related to proxy and www-authentication :(
The HTTP component is a TRUE beast.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 because SetReady is skipped with it's code related to proxy and www-authentication :( The HTTP component is a TRUE beast. Yes, it is! Is there not something like a full-blown http test tool which we can run against it and then start rewriting some parts to get it back in it's cage ? I found several on the web but have no idea if it has ever been used for THttpcli Can you locate that setready skipping somewhere? I have been maintenace programmer for a long time so used to reading others code but this one is hard to read and understand. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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) >> >> Thanks for the report. That's probably because SetReady is skipped >> with it's code related to proxy and www-authentication :( >> The HTTP component is a TRUE beast. > > Yes, it is! Is there not something like a full-blown http test tool > which we can run against it and then start rewriting some parts to > get it back in it's cage ? I found several on the web but have no > idea if it has ever been used for THttpcli > > Can you locate that setready skipping somewhere? My suggested fix did skip SetReady when FLocationFlag was set, it has to be removed. I have a new idea: in procedure THttpCli.StateChange(NewState : THttpState); try call TriggerRequestDone only when FLocationFlag is not set. However that might also lead to other side-effects I'm currently not aware of, it worked with and without proxy connection in a brief test. > I have been > maintenace programmer for a long time so used to reading others code > but this one is hard to read and understand. 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. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 behaviour but Im' sure you know that. When posting a message, the event handler will eventually be called, but only after all pending events including the current have been processed. Calling an event handler directly is just an immediate function call. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 follow relocation set)
>>>
>>> Thanks for the report. That's probably because SetReady is skipped
>>> with it's code related to proxy and www-authentication :(
>>> The HTTP component is a TRUE beast.
>>
>> Yes, it is! Is there not something like a full-blown http test tool
>> which we can run against it and then start rewriting some parts to
>> get it back in it's cage ? I found several on the web but have no
>> idea if it has ever been used for THttpcli
>>
>> Can you locate that setready skipping somewhere?
>
> My suggested fix did skip SetReady when FLocationFlag was set, it has
> to be removed. I have a new idea:
> in procedure THttpCli.StateChange(NewState : THttpState);
> try call TriggerRequestDone only when FLocationFlag is not set.
> However that might also lead to other side-effects I'm currently not
> aware of, it worked with and without proxy connection in a brief test.
That works for me as long as the proxy connection keeps alive after a
301/302. Otherwise it helps to clear the AuthStates in procedure
THttpCli.LocationSessionClosed.
{$IFDEF UseNTLMAuthentication}
FAuthNTLMState:= ntlmNone;
FProxyAuthNTLMState := ntlmNone;
{$ENDIF}
{$IFDEF UseDigestAuthentication}
FAuthDigestState := digestNone;
FProxyAuthDigestState := digestNone;
{$ENDIF}
FAuthBasicState := BasicNone;
FProxyAuthBasicState := BasicNone;
--
Arno Garrels
>
>> I have been
>> maintenace programmer for a long time so used to reading others code
>> but this one is hard to read and understand.
>
> 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.
>
> --
> Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 relocate is triggered (with follow relocation set)
Thanks for the report. That's probably because SetReady is skipped
with it's code related to proxy and www-authentication :(
The HTTP component is a TRUE beast.
>>>
>>> Yes, it is! Is there not something like a full-blown http test tool
>>> which we can run against it and then start rewriting some parts to
>>> get it back in it's cage ? I found several on the web but have no
>>> idea if it has ever been used for THttpcli
>>>
>>> Can you locate that setready skipping somewhere?
>>
>> My suggested fix did skip SetReady when FLocationFlag was set, it has
>> to be removed. I have a new idea:
>> in procedure THttpCli.StateChange(NewState : THttpState);
>> try call TriggerRequestDone only when FLocationFlag is not set.
>> However that might also lead to other side-effects I'm currently not
>> aware of, it worked with and without proxy connection in a brief
>> test.
>
> That works for me as long as the proxy connection keeps alive after a
> 301/302. Otherwise it helps to clear the AuthStates in procedure
> THttpCli.LocationSessionClosed.
>
> {$IFDEF UseNTLMAuthentication}
>FAuthNTLMState:= ntlmNone;
>FProxyAuthNTLMState := ntlmNone;
> {$ENDIF}
> {$IFDEF UseDigestAuthentication}
>FAuthDigestState := digestNone;
>FProxyAuthDigestState := digestNone;
> {$ENDIF}
>FAuthBasicState := BasicNone;
>FProxyAuthBasicState := BasicNone;
>
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 probably a buggy proxy server i.e. 3Proxy.
Parse NTLM user codes into domain and user name parts and pass them to
NtlmGetMessage3 in method GetNTLMMessage3.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 probably a buggy proxy server i.e. 3Proxy. Parse NTLM user codes into domain and user name parts and pass them to NtlmGetMessage3 in method GetNTLMMessage3. Arno, Thanks again for the work! I will make time next week to test together with the user that had the problem, so I know for sure it is solved :-) In the mean while i wrote a workaround by recalling the get and resetting the proxy values when a 407 was received. Easy to do in my application as that 407 should never happen at that moment. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 >> tested yet. >> If it still doesn't work it's probably a buggy proxy server i.e. >> 3Proxy. Parse NTLM user codes into domain and user name parts and >> pass them to NtlmGetMessage3 in method GetNTLMMessage3. >> > > Arno, Thanks again for the work! I will make time next week to test > together with the user that had the problem, so I know for sure it is > solved :-) What proxy server does your client use? Since I implemented HTTP tunnel support at the TWSocket level I've seen a lot of proxy-bugs :( That's also why it's difficult and very time-consuming to test the ICS components with proxy-connections. If we would strictly follow the rfcs 50% of the proxy servers around would just plain fail :( -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 your customer yet. I'm working on this stuff again since a couple of hours with some progress, I'll commit another fix soon when it's ready, not before monday. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 with some progress, I'll commit another fix soon when it's ready, not before monday. Ok ! There is other work laying around so... ;-) -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 on this stuff again since a couple of hours with some >> progress, I'll commit another fix soon when it's ready, not before >> monday. >> > Ok ! There is other work laying around so... ;-) Well, I just checked in a new change with log: Proxy authentication with relocations still did not work properly :( It's not perfect but works better now: Reset only NTLM AuthState in LocationSessionClosed and do not call SetReady while FLocationFlag is set, also call StartRelocation in GetHeaderLineNext if there's no body and the connection is not expected to close, also the relocation counter was incremented twice per relocation when the connection closed. Fix in Digest authentication. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
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'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 with >>> some progress, I'll commit another fix soon when it's ready, not >>> before monday. >>> >> Ok ! There is other work laying around so... ;-) > > Well, I just checked in a new change with log: Any progress with patch rev #669+ ? -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
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'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 with some progress, I'll commit another fix soon when it's ready, not before monday. Ok ! There is other work laying around so... ;-) Well, I just checked in a new change with log: Any progress with patch rev #669+ ? It's on my list to test this week. WIll let you know as soon as I have done my first test run. If that seems to work I will send it to a client to also test it. Thanks! -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
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'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 with some progress, I'll commit another fix soon when it's ready, not before monday. Ok ! There is other work laying around so... ;-) Well, I just checked in a new change with log: Any progress with patch rev #669+ ? It's on my list to test this week. WIll let you know as soon as I have done my first test run. If that seems to work I will send it to a client to also test it. Arno, 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" Used V7 daily archive download from the site for testing. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 OverbyteHttpAsy demo? Is it an URL publicly accessible? If yes, please send me that URL or post it to this list. Maybe the reason is not related to redirection and proxy usage at all? -- Arno Garrels - Original Message - From: "Frans van Daalen" To: "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'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 with >>>>>> some progress, I'll commit another fix soon when it's ready, not >>>>>> before monday. >>>>>> >>>>> Ok ! There is other work laying around so... ;-) >>>> >>>> Well, I just checked in a new change with log: >>> >>> Any progress with patch rev #669+ ? >>> >> >> It's on my list to test this week. WIll let you know as soon as I have >> done my first test run. If that seems to work I will send it to a client >> to also test it. >> > > Arno, > > 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" > > Used V7 daily archive download from the site for testing. > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 OverbyteHttpAsy demo? Is it an URL publicly accessible? If yes, please send me that URL or post it to this list. Maybe the reason is not related to redirection and proxy usage at all? 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. I can send you a few links but then again I do not know if those always generate that error. My test does a few thousand calls and some generate that error. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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" >> >> Are you able to reproduce the issue with OverbyteHttpAsy demo? Is it >> an URL >> publicly accessible? If yes, please send me that URL or post it to >> this list. >> Maybe the reason is not related to redirection and proxy usage at >> all? >> > > 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 or the VCL main thread, provided you did it all right. If the problem cannot be reproduced with one of the demo applications or with a simple, single threaded test application it's likely not a ICS-bug. > > I can send you a few links but then again I do not know if those > always generate that error. My test does a few thousand calls and > some generate that error. Thanks, received. Will try them the next days when I have some time. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 or the VCL main thread, provided you did it all right. If the problem cannot be reproduced with one of the demo applications or with a simple, single threaded test application it's likely not a ICS-bug. Arno, I owe you an apology! There are no problems reported in my software with the latest version ! Sorry! What happened is that the test runs more then several hours. I normally stop it after 45 mins because otherwise i need several days for just a few test runs. However when the thread terminates the calls to the getasync are not correctly stopped (!) and that is when the error start appearing. I saw this last night when i suddenly noticed that the timestamp for the error message was always at the same time as when terminating the thread. I will correct that issue and then run some extra tests to confirm that indeed when not using a proxy the issue is solved. Thanks again for your time! Frans -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
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 the >> context of a worker thread or the VCL main thread, provided you did >> it all right. If the problem cannot be reproduced with one of the >> demo applications or with a simple, single threaded test application >> it's likely not a ICS-bug. >> > > I owe you an apology! There are no problems reported in my software > with the latest version ! Sorry! No problem, that's good news. > > What happened is that the test runs more then several hours. I > normally stop it after 45 mins because otherwise i need several days > for just a few test runs. However when the thread terminates the > calls to the getasync are not correctly stopped (!) and that is when > the error start appearing. I saw this last night when i suddenly > noticed that the timestamp for the error message was always at the > same time as when terminating the thread. > > I will correct that issue and then run some extra tests to confirm > that indeed when not using a proxy the issue is solved. In my tests with several proxy-configurations it worked as well, knock on wood. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
