> You have a point, but let be more specific. For example, STAT returns one
> line for example "+OK 1 1452", USER, PASS, LIST n, "TOP n, m", etc, as
> well as any error command return one line: "-ERR". That mean that "+OK"
> follows other non-space characters return one line.
>
> Any LIST, UIDL, TOP n, RETR etc, return first line with only "+OK" and
> "."+CRLF at finish. That are multilines.
>
> According to upper, After analyze of first line you know is it receiving
> one line or more. That way you avoid mentioned problem with timeout, but
> add raw lines in RAW/FullResult without any parse.
You are not right at this point! Multilined response can have any
additional text after positive response code. You cannot detect
multilined responses by this! See RFC-1939 for details. See example for
LIST command from RFC, it is:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
> > This allows resume downloading... Firefox using it too!
>
> I'm sure for IE (4) behavior, it allow resuming only if you click again on
> exact download link EXACTLY after transfer break - otherwise temp file
> link is lost. With IE you can't see part of downloaded file in
> destination directory (it is somewhere in temp directory).
It is case of concrete implemetation, and it is totally out of this
discussion. All depending on how you impelment it, and it is possible to
implement it correctly.
> We discussing about unhandled error which can be easily be "part" of file.
> Problem is currently with HTTP.Documnt. What is needed is to handle code
> errors in app itself, since HTTP.Method('GET') will return no allarm on
> 416 or other than 204 and 304.
Yes, because you sucessfully contact HTTP server and sucessfully got
response! Response have some status code, some headers and optionally it
can have some document too. HTTP not doing difference between it. It is
just some code, some headers and some data as document. HTTP is just
transport protocol! Handling response, check if you got what you want
(status codes heklps you) is work for application logic, not for
transport logic. For someone are important data with status code 200, for
someone else are important datas with status code 404. All is possible!
I not wish to break this possibilities. In planning of next geneneration
of httpsend I must solve this problem. Maybey by some property, where you
can set some status codes, and if returned status code not match this set
of codes, then response will not be added to document. I must think about
it!
--
Lukas Gebauer.
E-mail: [EMAIL PROTECTED]
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP
Library
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
synalist-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synalist-public
