Hello Arno, I have successfully been able to reproduce the bug at: http://www.fastream.com/ics/httptstdemo.zip
Please examine the code for onrequestdone and press HEAD not get. It will first call head and then GET. Sometimes the url at: http://www.zaman.com.tr/haber.do?haberno=695444 fails to display the data of the GET as it sees the "0 \r\n" from HEAD command response and thinks the data is over when it wasn't even started! Please advise. Best Regards, SZ On Thu, May 29, 2008 at 4:58 PM, Arno Garrels <[EMAIL PROTECTED]> wrote: > > I call abort() when client > > socket is detected to be closed between each request and wait until > > requestdone, pumping messages in a while loop. Of course you should > > by now know that I use MT = true. > > If you need a true blocking method Abort that triggers RequestDone > before return you may want to add this change (tested only briefly): > > procedure THttpCli.Abort; > [..] > <= // StateChange(httpReady); { 13/02/99 } > => FState := httpReady; > => TriggerStateChange; > => WMHttpRequestDone(Msg); { Synchronous operation ! } > end; > > I guess this is a fix since Abort is/was intended to behave > blocking: "procedure Abort; { Synchrounous blocking Abort }". > AFAIR, TriggerRequestDone has been changed to post a message, I think > it triggered the event directly in some old versions. > > > Fastream Technologies wrote: > > Here is a question for you: In my derived class httpClient, I have > > some code such as, > > > > void __fastcall httpClient::SetReady() > > { > > if(alreadySetReady) > > return; > > alreadySetReady = true; // reset before each get, head, post... > > PostMessage(FHandle, FMsg_WM_HTTP_SET_READY, 0, 0); > > } > > > //--------------------------------------------------------------------------- > > Could this function pose a problem? I use this overriden function > > because otherwise there is no deterministic way to know the end of > > message calls in the component which is weak design since this causes > > problems in MT environment where you need to know the "end" to send > > to pool in the main thread. Hope you see the point. > > Looks at least rather suspicious. > > -- > Arno Garrels > > > > > Regards, > > > > SZ > > > > On Thu, May 29, 2008 at 1:01 PM, Fastream Technologies > > <[EMAIL PROTECTED]> wrote: > > > >> Unfortunately after your fix I am also unable to reproduce the bug > >> out of my own project in the ICS demo. :-(( Not sure what to do. > >> What I can tell you: in my project, I call abort() when client > >> socket is detected to be closed between each request and wait until > >> requestdone, pumping messages in a while loop. Of course you should > >> by now know that I use MT = true. > >> > >> SZ > >> > >> On Thu, May 29, 2008 at 11:25 AM, Arno Garrels > >> <[EMAIL PROTECTED]> wrote: > >> > >>> Fastream Technologies wrote: > >>>> For you, here is the list of events called with fast HEADs in > >>>> order: > >>>> > >>>> - OnHeaderData // header data here is "0". > >>>> - OnHeaderEnd > >>>> - OnSessionClosed > >>>> - OnHeaderData // header correct > >>>> - OnHeaderEnd // document could not be retrieved since connection > >>>> closed Regards, > >>> > >>> I cannot reproduce this issue in a simple test application with my > >>> little fix applied (running a loop of 20 Head/Get requests). > >>> Please send me a simple project that demonstrate the problem > >>> including the binary, I prefer a Delphi project, but it may be BCB > >>> as well. > >>> > >>> -- > >>> 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
