Fastream Technologies wrote:
> 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!

Sorry no idea :( It seems that if the request fails the "0 \r\n" is
sent so late that it's received as part of the reply to the GET request.
Then however the component handles Chunked Transfer Coding which leads 
to the problem.

Anyway this server is violating RFC2616 !!!
9.4 HEAD
   The HEAD method is identical to GET except that the server MUST NOT
   return a message-body in the response.

Note the "MUST NOT"!!

Also, did you note how they spell Connection?
it's "Cneonction: close" :)

--
Arno Garrels


 
> 
> 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

Reply via email to