Hello everybody,
I searched for a few hours now, but did not found a way to send a file by HTTP
POST using ICS HTTPCli.
I read that I need to MultiPart encode my stream, but found no function to do
it.
Is it possible ? How ? Got a sample somewhere ?
Regards,
Jacky Hicks
--
To unsubscribe or ch
Francois PIETTE wrote:
>> however the server obviously didn't call Data.ShutDown(1)
>> for some reason?
>
> One reason you could no see the shutdown packet is that the receiver
> stopped to receive data and the TCP window is full.
How would that be logged? I've nothing noted like that.
>
> btw:
Luciano Alves Barroso - DigiVoice wrote:
> remove my email from this list...
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>
>
Francois,
Then there are situations that your previous
argument will fail: Consider an application using
HttpCli that does not automatically encode URLs in
the URL property. Users will complain that "If I
enter in IE it works, but your
software is broken!". If your response is "have the
deve
Francois PIETTE wrote:
>>> The server can't be sure the file has been sent properly before the
>>> connection is properly closed.
>
>> That's true, however he knows that he sent all, he cannot know
>> whether it all received at the peer.
>
> He knows data is correctly received by the peer because
remove my email from this list...
--DigiVoice--
| Luciano Alves Barroso
| E-Mail: [EMAIL PROTECTED]
| Tel.: (11)2191-6362
| Site: http://www.digivoice.com.br
| http://www.meucci.org
-Desenvolvimento
- Segue mens
>> The server can't be sure the file has been sent properly before the
>> connection is properly closed.
> That's true, however he knows that he sent all, he cannot know
> whether it all received at the peer.
He knows data is correctly received by the peer because of the graceful
close sequence
> however the server obviously didn't call Data.ShutDown(1)
> for some reason?
One reason you could no see the shutdown packet is that the receiver stopped
to receive data and the TCP window is full.
btw: What do you use to format pcap data so that it is more readble ? (I
don't use Ethereal, I
> I do not agree that this is a relocation-specific
> issue, and if we want the component to mimic the
> expected behaviour of standard browsers, it needs to
> automatically encode all URLs when composing the
> request, at the latest point when the location
> address has been "commited" immutably.
Francois PIETTE wrote:
> The server can't be sure the file has been sent properly before the
> connection is properly closed.
That's true, however he knows that he sent all, he cannot know
whether it all received at the peer. So I think the response may be
sent after Data.ShutDown(1) at once, but
The server can't be sure the file has been sent properly before the
connection is properly closed. So it can't send the 226 answer before the
connection close is complete.
--
[EMAIL PROTECTED]
The author for the freeware multi-tier middleware MidWare
The author of the freeware Internet Component
>> May i send you my captured .pcap - file (148 KB) ?
>
> Yes, please send it.
Got it, uploaded a filtered version so others can take
a look at it as well:
http://www.duodata.de/misc/Patric-Flt1.pcap
This log shows that after the LIST command data was sent,
however the server obviously didn't ca
That's for general URI (Uniform Resource Identifier).
I believe RFC #1738 covers URL (Uniform Resource
Locator) specifically. It narrows down considerably
the scope of escaping as only a few valid
combinations, characters, and formats are valid for
WWW addresses.
-dZ.
>--- Original Mess
Patrick Schmidt - STEP Software GmbH wrote:
>> Possibly G6 works around that, have you tried Serv-U as well as
>> FileZilla server? If they all handle your client correctly we have to
>> find a workaround.
> I tried Filezilla Server and Serv-U. Both worked, see log.
Ohh, that's very interesting!
> Possibly G6 works around that, have you tried Serv-U as well as
> FileZilla server? If they all handle your client correctly we have to
> find a workaround.
I tried Filezilla Server and Serv-U. Both worked, see log.
Filezilla Server:
(31) 20.04.2007 15:57:33 - ma (192.168.200.179)> LIST
(00
[EMAIL PROTECTED] wrote:
>> --- Original Message ---
>>> From: Francois
> PIETTE[mailto:[EMAIL PROTECTED]
>> Sent: 4/19/2007 2:46:48 PM
>> To : twsocket@elists.org
>> Cc :
>> Subject : RE: Re: [twsocket] httpcli v6 "bad request"
>>
> >>> Agreed, so we need a FAST routine
Patrick Schmidt - STEP Software GmbH wrote:
>> I bet the delay starts after the server called Data.ShutDown(1)
>> in FtpSrv.pas, TFtpServer.WMFtpSrvCloseData, can you please
>> set a breakpoint there and check whether that this is true?
> I'm not shure, I set a breakpoint to this row: " Data.Shu
> I bet the delay starts after the server called Data.ShutDown(1)
> in FtpSrv.pas, TFtpServer.WMFtpSrvCloseData, can you please
> set a breakpoint there and check whether that this is true?
I'm not shure, I set a breakpoint to this row: " Data.ShutDown(1);
{ Wilfried 24/02/04 } "
but debuggin
18 matches
Mail list logo
