The problem is that the STATE is not ready after the abort, so when I use
httpcli to grab another file after a 302, I would get an error. (http
component busy, I think).
After an abort in such a case, is there anything that I have to do to make
sure that the component is ready for the next use?
(This only happens after a 302, anything else (200, 404, etc) works well.)
-Ronny
Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 3:59 AM
Subject: Re: [twsocket] HttpCli problem

>After httpcli.abort is called, the statuscode is normally 404 if the
>statuscode before the call is 200. The statuscode is 0 if the original
>statuscode is 302. This is causing me problems (i.e. httpcli state is
>not
>ready after an abort is called if the statuscode was 302). See example:
>>
>log.Lines.Add(inttostr(httpcli.StatusCode);
>httpcli.abort;
>log.Lines.Add(inttostr(httpcli.StatusCode);
>>
>D7, ICS V6 beta V1.91
>
StatusCode value is valid only when or after RequestDone has been
triggered.
Anyway, if you abort, you obviously know what you are doing. No need to
rely
on StatusCode.

I did find a work-around, but it is not pretty:

while httpcli.State <httpready do
begin
a:=a+1;
log.Lines.add('Waiting '+inttostr(a));
application.ProcessMessages;
end;

This is only needed after a 302. The counter ranges from 400-1000 before
the state turns to httpready. And I am not sure that they are real 302s.
The same pages give a statuscode of 302 consistently when downloaded in the
same order, but may give a 200 if downloaded in a different order. Could a
bug in my program make httpcli give a fake 302 statuscode?
(The above code gives an infinite loop if application.processmessages is
removed)

Message
From: "Ronny" <overbyte (AT) surfwarelabs (DOT) com>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 10:08 AM
Subject: Re: [twsocket] HttpCli problem

The problem is that the STATE is not ready after the abort, so when I use
httpcli to grab another file after a 302, I would get an error. (http
component busy, I think).
After an abort in such a case, is there anything that I have to do to make
sure that the component is ready for the next use?
(This only happens after a 302, anything else (200, 404, etc) works well.)
-Ronny

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 3:59 AM
Subject: Re: [twsocket] HttpCli problem
--
After httpcli.abort is called, the statuscode is normally 404 if the
statuscode before the call is 200. The statuscode is 0 if the original
statuscode is 302. This is causing me problems (i.e. httpcli state is
not
ready after an abort is called if the statuscode was 302). See example:

log.Lines.Add(inttostr(httpcli.StatusCode);
httpcli.abort;
log.Lines.Add(inttostr(httpcli.StatusCode);

D7, ICS V6 beta V1.91
>>
>StatusCode value is valid only when or after RequestDone has been
>triggered.
>Anyway, if you abort, you obviously know what you are doing. No need to
>rely
>on StatusCode.
>>
>--
>francois.piette (AT) overbyte (DOT) be
>http://www.overbyte.be
>>
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be
>

Hello Ronny,

The problem is that the STATE is not ready after the abort

Do you also mean that RequestDone is "not" fired after Abort ? Because
normally this is the place to check if component is ready, and when it
is then take next action.

If this is the case then I assume state will be ready immediatly after
abort. So you can take the next action probably in a custom message
handler.

Rgds, Wilfried [TeamICS]

http://www.mestdagh.biz

Saturday, February 25, 2006, 16:08, Ronny wrote:

The problem is that the STATE is not ready after the abort, so when I use
httpcli to grab another file after a 302, I would get an error. (http
component busy, I think).
After an abort in such a case, is there anything that I have to do to make
sure that the component is ready for the next use?
(This only happens after a 302, anything else (200, 404, etc) works well.)
-Ronny

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 3:59 AM
Subject: Re: [twsocket] HttpCli problem

After httpcli.abort is called, the statuscode is normally 404 if the
statuscode before the call is 200. The statuscode is 0 if the original
statuscode is 302. This is causing me problems (i.e. httpcli state is
not
ready after an abort is called if the statuscode was 302). See example:

log.Lines.Add(inttostr(httpcli.StatusCode);
httpcli.abort;
log.Lines.Add(inttostr(httpcli.StatusCode);

D7, ICS V6 beta V1.91
>>
>StatusCode value is valid only when or after RequestDone has been
>triggered.
>Anyway, if you abort, you obviously know what you are doing. No need to
>rely
>on StatusCode.
>>
>--
>francois.piette (AT) overbyte (DOT) be
>http://www.overbyte.be
>>
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

The problem is that the STATE is not ready after the abort, so when I use
httpcli to grab another file after a 302, I would get an error. (http
component busy, I think).
After an abort in such a case, is there anything that I have to do to make
sure that the component is ready for the next use?
(This only happens after a 302, anything else (200, 404, etc) works well.)

Use the RequestDone event which is triggered if you abort while an
operation was already started (the componentis busy).

Why use a loop ?
Why don't you want to use RequestDone event ?

That is the problem. This routine is called from RequestDone. That is why
I think that there is a bug. RequestDone gets called twice for 302s, but
I have already taken that into account.
Should httpcli.State = httpReady when RequestDone is called? If so, this
is not the case with 302.

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 11:22 AM
Subject: Re: [twsocket] HttpCli problem

Why use a loop ?
Why don't you want to use RequestDone event ?

>Why use a loop ?
>Why don't you want to use RequestDone event ?

That is the problem. This routine is called from RequestDone. That is
why
I think that there is a bug. RequestDone gets called twice for 302s,
but
I have already taken that into account.
Should httpcli.State = httpReady when RequestDone is called? If so,
this
is not the case with 302.

There is no reason to call Abort from RequestDone which is the time when
the request is done !
Why do you think you need to call Abort from RequestDone ?
I you really have a good reason (I like to hear it), then PostMessage a
custom message and then exit. Then from the corresponding event handler,
call Abort.

Hello Ronny,

Should httpcli.State = httpReady when RequestDone is called? If so, this
is not the case with 302.

No becase RequestDone is called in different states. You have to put
there a case statement. And when state is httpREady then you do next
grab.

But you where talking of Aboft metht in another mail. I think
Reqeustdone is also called when you call Abort if state is not yet
httpReady.

Rgds, Wilfried [TeamICS]

http://www.mestdagh.biz

Saturday, February 25, 2006, 17:46, Ronny wrote:

That is the problem. This routine is called from RequestDone. That is why
I think that there is a bug. RequestDone gets called twice for 302s, but
I have already taken that into account.
Should httpcli.State = httpReady when RequestDone is called? If so, this
is not the case with 302.

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 11:22 AM
Subject: Re: [twsocket] HttpCli problem


>Why use a loop ?
>Why don't you want to use RequestDone event ?
>--
>francois.piette (AT) overbyte (DOT) be
>http://www.overbyte.be
>>
>Message
>From: "Ronny" <overbyte (AT) surfwarelabs (DOT) com>
>To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
>Sent: Saturday, February 25, 2006 4:57 PM
>Subject: Re: [twsocket] HttpCli problem
>>
>>
I did find a work-around, but it is not pretty:

while httpcli.State <httpready do
begin
a:=a+1;
log.Lines.add('Waiting '+inttostr(a));
application.ProcessMessages;
end;

This is only needed after a 302. The counter ranges from 400-1000 before
the state turns to httpready. And I am not sure that they are real 302s.
The same pages give a statuscode of 302 consistently when downloaded in
the
same order, but may give a 200 if downloaded in a different order. Could
a
bug in my program make httpcli give a fake 302 statuscode?
(The above code gives an infinite loop if application.processmessages is
removed)

Message
From: "Ronny" <overbyte (AT) surfwarelabs (DOT) com>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 10:08 AM
Subject: Re: [twsocket] HttpCli problem

The problem is that the STATE is not ready after the abort, so when I
use
httpcli to grab another file after a 302, I would get an error. (http
component busy, I think).
After an abort in such a case, is there anything that I have to do to
make
sure that the component is ready for the next use?
(This only happens after a 302, anything else (200, 404, etc) works
well.)
-Ronny

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 3:59 AM
Subject: Re: [twsocket] HttpCli problem

After httpcli.abort is called, the statuscode is normally 404 if the
statuscode before the call is 200. The statuscode is 0 if the
original
statuscode is 302. This is causing me problems (i.e. httpcli state is
not
ready after an abort is called if the statuscode was 302). See
example:

log.Lines.Add(inttostr(httpcli.StatusCode);
httpcli.abort;
log.Lines.Add(inttostr(httpcli.StatusCode);

D7, ICS V6 beta V1.91

StatusCode value is valid only when or after RequestDone has been
triggered.
Anyway, if you abort, you obviously know what you are doing. No need to
rely
on StatusCode.

--
francois.piette (AT) overbyte (DOT) be
http://www.overbyte.be

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be

--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at http://www.overbyte.be
>>
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

Thank you for the feedback, Francois and Wilfried. I have not been clear in
my explination. Let me start again with more detail:

State: httpReady
I call httpcli.GetASync.
State: httpDnsLookup

( on HeaderEnd)
State: httpWaitingHeader StatusCode: 302
I call httpcli.About
State: httpReady

(RequestDone)
State: httpDNSLookup

Nothing is done between HeaderEnd and RequestDone, so I assume that
httpcli is looking for the redirect. (This only happens with a 302
StatusCode, with a 200 Statuscode, RequestDone state is httpReady).

If this is a 'Feature' and not a bug, then can I Abort again in the
RequestDone? what do you recommend? I do not think that the second
DNSLookup will provide me with any useful information, even if it is a
redirect, I wouldn't know how to use it, so I might as well cancel it and
try to get the next file.

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Saturday, February 25, 2006 1:12 PM
Subject: Re: [twsocket] HttpCli problem

Why use a loop ?
Why don't you want to use RequestDone event ?
>
>That is the problem. This routine is called from RequestDone. That is
>why
>I think that there is a bug. RequestDone gets called twice for 302s,
>but
>I have already taken that into account.
>Should httpcli.State = httpReady when RequestDone is called? If so,
>this
>is not the case with 302.
>
There is no reason to call Abort from RequestDone which is the time when
the request is done !
Why do you think you need to call Abort from RequestDone ?
I you really have a good reason (I like to hear it), then PostMessage a
custom message and then exit. Then from the corresponding event handler,
call Abort.

Thank you for the feedback, Francois and Wilfried. I have not been clear
in
my explination. Let me start again with more detail:

Before I answer more, probably for nothing, please answer the questions I
asked in my previous mail:

>There is no reason to call Abort from RequestDone
>which is the time when the request is done !
>Why do you think you need to call Abort from RequestDone ?

This is really important you answer the questions.
Giving details on what you see in your program is not relevant until I
understand what you want to do. You have to explain at a much higher level
than giving details about status code.
State variable is just for information. You_must_ use the events. You can't
poll the state and do whatever you want. has to be done from the
events or _after_ RequestDone event. Abort can be called at anytime,
outside of any event and the result is unpredictable except the fact that
the current operation will be aborted or course.

Computers are not my strength, so I am trying my best to speak in your
language.

There is no reason to call Abort from RequestDone
which is the time when the request is done !
Why do you think you need to call Abort from RequestDone ?

I do NT want to call Abort from RequestDone. It is called from
HeaderEnd.

This is really important you answer the questions.
Giving details on what you see in your program is not relevant until I
understand what you want to do. You have to explain at a much higher level
than giving details about status code.
State variable is just for information. You_must_ use the events. You
can't
poll the state and do whatever you want. has to be done from
the
events or _after_ RequestDone event. Abort can be called at anytime,
outside of any event and the result is unpredictable except the fact that
the current operation will be aborted or course.

Here is how I handle events:

, to download several files, very similar to the Httpasy demo:
GoButton.Click: HttpCli.GetASync
HeaderEnd: Check if the file to be downloaded is good. If not, ABRT.
RequestDone: If ABRT, then clear the file, if not store the downloaded
file. Then get the next file.

The problem is that IF the statuscode is 302 and I Abort, then I cannot get
the next file because the component is busy. (httpDNSLookup).
I have solved this problem by having the first line in RequestDone check
the status, and only execute the routine if it is httpReady.
(i.e.
Procedure RequestDone
begin
if httpcli.state = httpReady then
begin
the rest of the RequestDone code;
end;
end;
)
My question is: Is there a bug in the component, or is there a better
method of doing this?

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 26, 2006 6:21 AM
Subject: Re: [twsocket] HttpCli problem


>Thank you for the feedback, Francois and Wilfried. I have not been clear
>in
>my explination. Let me start again with more detail:
>
Before I answer more, probably for nothing, please answer the questions I
asked in my previous mail:

Here is how I handle events:

, to download several files, very similar to the Httpasy demo:
GoButton.Click: HttpCli.GetASync
HeaderEnd: Check if the file to be downloaded is good. If not, ABRT.
RequestDone: If ABRT, then clear the file, if not store the downloaded
file. Then get the next file.

Ah ! That's better explanation.
>From the HeaderEnd, set a flag to remember the file is not good and then
use PostMessage with a cutom message. From the event handler, call Abort if
RequestDone has not been called already. From the RequestDone event,
check your flag to know if the file is K or not and process accordingly.
Ignore any error condition if the flag is set because Abort has been called.

It is always better to use PostMessage to defer any processing out of any
event handler. At the time an custom message is handled, the component is
out of his own work. If you put the processing in the event handler and this
processing involve the component itself, then it is likely you'll have
problems because when the event handler is returns, the component continue
what it has started and which maybe the wrong thing if you changed the
instructions ! course it the processing doesnt' involve the component
itself, there is no problem.

The problem is that IF the statuscode is 302 and I Abort, then I cannot
get
the next file because the component is busy. (httpDNSLookup).

You can turn "followRelocation" to false and handle the relocation yourself
if this problem still happend with the change I outlined above.

My question is: Is there a bug in the component, or is there a better
method of doing this?

No bug that I'm aware. Follow the outline I gave above.

Thank you, these are just the answers that I need!
-Ronny

Message
From: "Francois PIETTE" <francois.piette (AT) overbyte (DOT) be>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, February 26, 2006 11:51 AM
Subject: Re: [twsocket] HttpCli problem


>
>Here is how I handle events:
>>
>, to download several files, very similar to the Httpasy demo:
>GoButton.Click: HttpCli.GetASync
>HeaderEnd: Check if the file to be downloaded is good. If not, ABRT.
>RequestDone: If ABRT, then clear the file, if not store the downloaded
>file. Then get the next file.
>
Ah ! That's better explanation.
>>From the HeaderEnd, set a flag to remember the file is not good and then
use PostMessage with a cutom message. From the event handler, call Abort
if
RequestDone has not been called already. From the RequestDone event,
check your flag to know if the file is K or not and process accordingly.
Ignore any error condition if the flag is set because Abort has been
called.

It is always better to use PostMessage to defer any processing out of any
event handler. At the time an custom message is handled, the component is
out of his own work. If you put the processing in the event handler and
this
processing involve the component itself, then it is likely you'll have
problems because when the event handler is returns, the component continue
what it has started and which maybe the wrong thing if you changed the
instructions ! course it the processing doesnt' involve the component
itself, there is no problem.
>
>The problem is that IF the statuscode is 302 and I Abort, then I cannot
>get
>the next file because the component is busy. (httpDNSLookup).
>
You can turn "followRelocation" to false and handle the relocation
yourself
if this problem still happend with the change I outlined above.
>
>My question is: Is there a bug in the component, or is there a better
>method of doing this?
>
No bug that I'm aware. Follow the outline I gave above.