[twsocket] FTPCli error handling
Hello all, it's me again and again with a question about FTPCli. Current manner of reporting local errors is to set code 550 with an explaining message and call TriggerRequestDone. But I find it very confusing: for example, when trying to GET some file or directory listing we could receive "true FTP response" 550 if the requested file doesn't exist (so we should give up) as well as "ICS response" if connection couldn't be established (so we should retry) or there was error creating local file stream (so we should check HDD free space). And there's no way to distinguish these cases (except checking FLastResponse string, but I consider it rather unconvenient). So I think something is needed to be done to differentiate local problems of remote ones. I'd prefer changing 550 code to some another value unused by FTP servers (maybe even over 600 to avoid intersections for sure) but the ICS policy is NOT BREAK existing code, so maybe some flag like FLocalErrorHappened: Boolean will solve the problem? If you reject the idea please explain me how to deal with this response mess. -- Anton -- 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
Re: [twsocket] help to convert from utf8 to ansi (locale)
Hi RTT Yes I use UrlDecode from OverbyteIcsUrl.hpp with defaults SrcCodePage and DetectUtf8. Alternative, I not found other, was include Indy component but using ICS I think isn't unnecessary. I will check using no default parameters. Thanks again Xavi Al 29/04/2010 03:16, En/na RTT ha escrit: Hi Xavier, The UTF8Decode is being performed automatically probably because you are using the UrlDecode function from OverbyteIcsHttpSrv. If you check its definition, function UrlDecode(const Url: string; SrcCodePage: LongWord = CP_ACP; DetectUtf8: Boolean = TRUE): string; there is a, default set to true, parameter, DetectUtf8, to define if the auto-detection, and decoding, of UTF8 encoded strings must be made automatically by the function after the URLDecode conversion Hi RTT Thanks for your tips. Finally I get it work but I should write code a bit different String usStr; (or UnicodeString usStr;) AnsiString asStr; usStr = URLDEcode( "Sin%20t%C3%ADtulo%201_html_m5b7e3440.jpg" ); asStr = usStr; <--- Compiler introduce required conversion code using asStr = UTF8Decode( usStr ); or asSTR = UTF8Decode( URLDEcode( "Sin%20t%C3%ADtulo%201_html_m5b7e3440.jpg" ) ); give asStr = NULL I think D2009 and BC2009 works diferent when doing inline automatic conversions. Many thanks for all Xavi -- 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 Se certifico que el correo entrante no contiene virus. Comprobada por AVG - www.avg.es Version: 9.0.814 / Base de datos de virus: 271.1.1/2840 - Fecha de la version: 04/28/10 08:27:00 -- Xavier Mor-Mur -- 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
Re: [twsocket] help to convert from utf8 to ansi (locale)
Hello Arno Thanks your comments. I need update my head from ansi to unicode :-) Should not be problem, or that I think, converting unicode encoded files to ansi. as all files will created on local network. I will read a bit more about differences between UTF8String and UnicodeString, help from BC2009 is not clear. Xavi Al 29/04/2010 08:54, En/na Arno Garrels ha escrit: Xavier Mor-Mur wrote: String usStr; (or UnicodeString usStr;) AnsiString asStr; usStr = URLDEcode( "Sin%20t%C3%ADtulo%201_html_m5b7e3440.jpg" ); asStr = usStr;<--- Compiler introduce required conversion code using asStr = UTF8Decode( usStr ); or asSTR = UTF8Decode( URLDEcode( "Sin%20t%C3%ADtulo%201_html_m5b7e3440.jpg" ) ); Conversion from Unicode to AnsiString might lead to dataloss, whether the source be UTF-8 or UTF-16. If you actually need a AnsiString with code page CP_UTF8 you should use type UTF8String instead of AnsiString. Since 2009 the compiler is code page aware and implicitly converts between UTF8String and (Unicode)String without dataloss and warnings. In this case one could also write a slighty different version of UrlDecode() that returned a UTF8String to save a few conversions. -- 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 Se certifico que el correo entrante no contiene virus. Comprobada por AVG - www.avg.es Version: 9.0.814 / Base de datos de virus: 271.1.1/2840 - Fecha de la version: 04/28/10 08:27:00 -- Xavier Mor-Mur -- 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
Re: [twsocket] FTPCli error handling
Anton Sviridov wrote: > unconvenient). So I think something is needed to be done to > differentiate local problems of remote ones. I'd prefer changing 550 > code to some another value unused by FTP servers (maybe even over 600 > to avoid intersections for sure). > but the ICS policy is NOT BREAK existing code, Yes, this is the policy, it has pros and cons. > so maybe some flag like FLocalErrorHappened: Boolean > will solve the problem? I haven't looked at the FTP-Client component for a long time. If a workaround is needed then IMO a field "FLastLocalError" of type LongWord or Integer could receive a meaningful error code and a method GetLastLocalError could return and reset the value back to 0? -- 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
Re: [twsocket] FTPCli error handling
Hello Arno, >If a workaround is needed then IMO a field "FLastLocalError" of type >LongWord or Integer could receive a meaningful error code and a method >GetLastLocalError could return and reset the value back to 0? Well, it's something. Though I'm still not sure what's the best way to deal with the issue. Any flag or value must be somehow cleared after reporting (though TriggerRequestDone seems to be a nice place for it). Maybe something like OnLocalError handler will work... unfortunately currently I have no idea of how to inject the workaround into the existing code properly. -- Anton -- 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
Re: [twsocket] FTPCli error handling
Have you tried calling GetLastError or WSAGetLastError ? -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: "Anton Sviridov" To: Sent: Thursday, April 29, 2010 2:20 PM Subject: [twsocket] FTPCli error handling Hello all, it's me again and again with a question about FTPCli. Current manner of reporting local errors is to set code 550 with an explaining message and call TriggerRequestDone. But I find it very confusing: for example, when trying to GET some file or directory listing we could receive "true FTP response" 550 if the requested file doesn't exist (so we should give up) as well as "ICS response" if connection couldn't be established (so we should retry) or there was error creating local file stream (so we should check HDD free space). And there's no way to distinguish these cases (except checking FLastResponse string, but I consider it rather unconvenient). So I think something is needed to be done to differentiate local problems of remote ones. I'd prefer changing 550 code to some another value unused by FTP servers (maybe even over 600 to avoid intersections for sure) but the ICS policy is NOT BREAK existing code, so maybe some flag like FLocalErrorHappened: Boolean will solve the problem? If you reject the idea please explain me how to deal with this response mess. -- Anton -- 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
Re: [twsocket] FTPCli error handling
>Have you tried calling GetLastError or WSAGetLastError ? I think it's unreliable because error can occur by exception not by Winsock or Windows error. Moreover, LastError-s could be overwritten by subsequent API calls by the moment OnRequestDone will be called. -- Anton -- 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
