In a D2010 VCL project running on XP SP3 and later, TIdLPR.Connect() is able to connect to the print server exactly one time, then afterwards an exception with socket error 10048 is raised until the OS releases the first socket from FD_WAIT status.

procedure TForm1.Button1Click(Sender: TObject);
begin
  IdLPR1.Host := '192.168.101.104'; // 'brn_906b9b';
  IdLPR1.Queue := 'BINARY_P1';
  
  IdLPR1.BoundIP := GStack.LocalAddress;
  Memo1.Lines.Add('Local Address: ' + IdLPR1.BoundIP);
  
  IdLPR1.Connect;
  try
    IdLPR1.PrintFile('myfile.prn');
  finally
    IdLPR1.Disconnect;
  end;
end;

Using the attached project, here are the results I see in Delphi 2010:

ISO-8859-1

Euro symbol encoded as '?' - OK (not suported).
German symbols encoded as-is - OK.

7bit:
All encoded codeunits sent as-is rather than as ASCII - BUG.

all other encodings:
All OK.

ISO-8859-15

Euro symbol encoded as '¤' - WEIRD, NEEDS REVIEW.
German symbols encoded as-is - OK.

7bit:
Euro symbol decoded as '$' - WEIRD, NEEDS REVIEW.
German encoded codeunits sent as-is rather than as ASCII - BUG.

8bit, binary, binhex40:
Euro symbol decoded as '¤' - OK BUT WEIRD.
German symbols OK.

base64, quoted-printable:
All OK.

UTF-8

All symbols encoded OK.

7bit:
All encoded codeunits sent as-is rather than as ASCII - BUG.

8bit, binary, binhex40:
All encoded codeunits sent OK
All encoded codeunits decoded as-is rather than as UTF-8 - BUG

all other encodings:
All OK.

The TThread.Resume() and TThread.Suspend() methods have been deprecated in Delphi 2010. Indy needs to be updated to stop using them, and instead implement its own pause and resume functionality that is more thread-safe, such as by using a pause event object.

In the meantime, can use TIdThread.Suspended:=True and TIdThread.Suspended:=False instead.

The initialization order of the IdHeaderCoder... units is different between Delphi and C++Builder, causing encoding/decoding problems at run-time in C++ projects because the TIdHeaderCoderPlain class is being used when the TIdHeaderCoderIndy class should be used instead.

After reviewing the code, the entire IdHeaderCoder sub-system can be completely removed from Indy. There is adaquate support for the TIdTextEncoding class in Indy's core, specifically the existing CharsetToEncoding() function, that IdCoderHeader.pas can now make direct use of TIdTextEncoding with minimal changes to its algorithms (the only piece that would need to be re-implemented is to move the TIdHeaderCoderISO2022JP class logic into a new TIdTextEncoding descendant class, and then have CharsetToEncoding() use it when no OS/Iconv support is available for Japanese encodings).

This also helps better centralize Indy's text encoding/decoding capabilities by using TIdTextEncoding more, making future text encoding schemes easier to implement.

With FIPS-complience, we will need to provide more secure SASL mechanisms than what Indy currently has. Many SASL mechanism such as Digest, OTP, CRAM-MD5, and S/Key use compromised hash algorithms. SHA1 also has been partially compromised so we need SASL mechanisms that use stronger hashing that are FIPS approved such as SHA224, SHA256, SHA384, and SHA512. Suggest starting off with SCRAM.

http://tools.ietf.org/html/draft-ietf-sasl-scram-10

Note that code has been checked that does HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 so SCRAM should be doable.

Indy stores most of its compiler conditional defines in IdCompilerDefines.inc, but this file is only usable in Delphi code. There is no corresponding file for use in C++Builder. If nothing else, Indy could use {$HPPEMIT} statements in IdGlobal.pas (or maybe a new unit like IdCompilerDefines.pas) for the more important defines, such as the version number.

Look for open Indy issues in http://quality.embarcadero.com

IdHash.pas does not compile in .NET:

[DCC Error] IdHash.pas(381): E2003 Undeclared identifier: 'TransformFinalBlock'
[DCC Error] IdHash.pas(382): E2003 Undeclared identifier: 'Hash'
[DCC Error] IdHash.pas(451): E2003 Undeclared identifier: 'TransformBlock'

Offhand, it looks like the TIdHashIntCtx type was intended to be an alias for the .NET HashAlgorithm class, but it is not actually declared that way. TIdHashIntCtx is an alias for an IntPtr instead.

The implementation of TIdFTP.DisconnectNotifyPeer() was changed in SVN Tiburon branch revision 3971. Since then, there have been several reports of socket errors being raised when disconnecting from an FTP server.

Old code:

procedure TIdFTP.DisconnectNotifyPeer;
begin
  if IOHandler.Connected then begin
    IOHandler.WriteLn('QUIT');      {do not localize}
  end;
  if IOHandler.Connected then begin
    if IOHandler.Readable(10) then begin
      GetInternalResponse;
    end;
  end;
end;

New code:

procedure TIdFTP.DisconnectNotifyPeer;
begin
  if IOHandler.Connected then begin
    IOHandler.WriteLn('QUIT');      {do not localize}
    IOHandler.CheckForDataOnSource(100);
    if not IOHandler.InputBufferIsEmpty then begin
      GetInternalResponse;
    end;
  end;
end;

Add support for SSH

Add 8BITMIME support to TIdSMTP.Send()

RFC 3023 defines the semantics of XML media types in HTTP and MIME processing. In particular, how the XML content's charset should be determined when omitted from a Content-Type header. These rules differ from other RFCs that define default charsets for textual data.

Add a UIDL collection to TIdPOP3, which reports the MsgNo and ID of each message reported by the UIDL command.

Various platforms, like Windows Vista+, Linux, etc support dual-stack sockets, meaning a socket can handle both IPv4 and IPv6 traffic on a single socket endpoint. For servers, this means a single listening socket can accept both IPv4 and IPv6 clients. For clients, this means a single socket can connect to both IPv4 and IPv6 servers.

Add OnThreadStartup/Shutdown events and virtual methods to TIdSchedulerOfThread and have them be called by TIdThread.Before/AfterExecute(). This way, users can perform per-thread initializations/cleanups, such as calling CoInitialize/Ex() and CoUninitialize().

Look into using IcmpCreateFile() and related functions on Windows 2000+.

TIdEmailAddress fails for a valid address like

"Sm\"art\"POP@JAM" <[email protected]>

Code to reproduce:

var 
  addr: TIdEMailAddressItem; 
  decodedFrom, parsedAddr: WideString;
begin
  decodedFrom := '"Sm\"art\"POP@JAM" <[email protected]>';
  addr.Text := decodedFrom;
  parsedAddr := addr.Text;
  Assert(SameText(parsedAddr, decodedFrom), 'Addresses are not equal:' + parsedAddr + ' <--> ' + decodedFrom);
end;

The problem is now that name contains the value including the quoted (quoted with '') double quotes. Then the quote symbol '' is duplicated when using the GetText function:

"Sm\\"art\\"POP@JAM" <[email protected]>

More addresses:

addr.Text := '<[email protected]>';

Results in an Address of '<[email protected]'

addr.Text := '<<[email protected]>>';

Results in an Address of '<<[email protected]'

Another example:

addr.Text := '"name" <"user"@domain>';

Results in a Name of 'name" <"user' and an Address of '@domain>'

More examples:

addr.Text := '"This is \\" <[email protected]>';

Results in a Name of 'This is \\' instead of 'This is \'.

addr.Text := '"This is \" \\" <[email protected]>';

Results in a Name of 'This is \" \\' instead of 'This is " \'.

Internationalization of the File Transfer Protocol
http://www.ietf.org/rfc/rfc2640.txt

UTF-8 Option for FTP
http://tools.ietf.org/html/draft-ietf-ftpext-utf-8-option-00

Delphi 2010 introduces a new 'delayed' keyword for delay-loading of DLL functions. Indy's manual calls to LoadLibrary() and GetProcAddress() can be replaced with this feature, allowing for much cleaner code. In the event that a DLL function cannot be found (older OS version, wrong DLL version, etc), the System.SetDliFailureHook() callback can be used to handle that.

Update TIdIOHandler to pass its ConnectTimeout value all the way to TIdStack.Connect() to get the timeout logic out of TIdIOHandler.ConnectClient(). This way, TIdStackWindows can be updated to use WSA...() functions when available (ie, WSAConnectByName() or WSAConnectByList(), which both have a timeout parameter), and thus avoid having to use the TIdConnectThread class to abort the connection after the timeout elapsed. Other TIdStack... classes can continue using TIdConnectThread when suitable platform-specific techniques are not available.

Excecuting TIdFTP.Get() results in an access violation in D5. See attached call stack. The call to Get is Get('cashmondat.zip', 'cashmondat.zip', True, false).

TIdTextEncoding.GetByteCount(TIdWideChars, Integer, Integer) is being passed an invalid ACharCount parameter value. The corrupted value would have to be coming from the call to Length(AChars) in TIdTextEncoding.GetByteCount(TIdWideChars). TIdWideChars is an array of WideChar in D5, and the call stack shows valid contents for the array in the AChars parameter of GetByteCount().

Stepping inside the CPU window into:

Result := GetByteCount(@AChars[ACharIndex], ACharCount);

call dword ptr [ebx] uses a wrong address.

Previous calls that worked ok used EAX=73EB8, now it uses 6DDAFF instead. This results to the wrong value in EBX.

Reimplement TIdCriticalSection using spin-lock implementation by Istvan Agoston and was based on this:
http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/333935.htm

Found it from here (while looking something completely different):
http://17slon.com/gp/gp/gplists.htm

Need to double-check how TIdHTTP, TIdHTTPServer, and TIdHTTPProxyServer handle the "Expect" header, particularly in regard to the "100-continue" expectation. Have seen some reports that suggest improper handling may be causing timeout problems.

See http://en.wikipedia.org/wiki/Category:Binary-to-text_encoding_formats

The ContentRangeStart and ContentRangeEnd properties do not currently apply to HTTP requests, but they are accessible in TIdHTTPRequest. Either make them update the Range property, or else remove them from TIdHTTPRequest so they do not confuse people anymore.

Try to optimize TIdIOHandler.ReadStream() to make it faster. One idea is to pre-allocate its local read buffer once and not re-allocate it on each new block of data that is received.

According to Wireshark, TIdSNMP.Trap is encoding the PDU type as 0x24 instead of 0xA4, and reports that BER offsets are wrong.

Also, TSNMPInfo.EncodeTrap() encodes all MIB values as ASN1_OCTSTR instead of respecting the assigned object type, like TSNMPInfo.EncodeBuf() does.

I will have to check on the PDU type issue.

EncodeTrap() was updated on Oct 20 2010 in rev 4474 to respect assigned MIB value types.

Users have more or less only two places where they can plug code inside the HTTP response generation: OnHeaderAvailable/OnHeadersBlocked and OnCommandGet/OnCommandOther. Unfortunately, OnHeaderAvailable happens very early in the processing and does not give much options: the headers are fully unparsed and the user cannot give a reason why the operation is canceled (this reason can be provided through OnHeaderBlocked but that requires additional code to save the error inside the connection context).

Unfortunately, large requests causes two issues:

• Anonymous connections can cause DOS through a resource exhaustion because the request size isn't checked and memory is pre-allocated (i.e. ask for 4 gigs of data you you'll kill the process outright).
• Users are warned of errors only AFTER the whole stream has been sent.

Either merge the OnHeadersAvailable and OnHeadersBlocked events together, or add a new OnHeaderAvailableEx event. Also need to validate that the request post stream size can be handled by the underlying OS platform (ie, do not allow 2+ GB on a 32-bit system when using TMemoryStream, etc).

TIdMappedFTP needs to support the IPv6 commands and commands such as MLSD. We might also need to support a IMG command. It's in an Internet Draft and is used by FTP voyager.

See https://github.com/tothpaul/Delphi/tree/master/Indy.SChannel for a 3rd party implementation.

Also of note: https://github.com/Fr0sT-Brutal/Delphi_SChannelTLS#note---schannel-bug

I think we need to support multi-byte strings in SASL. In order to do this, we need to implement RFC 3454 Preparation of Internationalized Strings ("stringprep")

When receiving directory listings from an FTP server, TIdFTP applies text charset decoding, based on whether UTF-8 was negotiated or not, before the FTP listing parsers are invoked to parse the data. The parser classes may need to be updated to allow TIdFTP to pass the raw undecoded data to them instead of TIdFTP itself interpretting the raw data.

TIdAuthenticationNTLM needs to be fixed to work correctly in D2009.

Update TIdHTTPProxyServer to support caching and chunked/compressed transfers

Architecural changes in Indy 10's I/O system over previous versions have broken TIdHL7. It needs to be fixed.

TIdFTP.List() does the following:

FListResult.Text := ReadStringFromStream(LDest, -1, IOHandler.DefStringEncoding);

The IOHandler.DefStringEncoding is set to TIdTextEncoding.UTF8 beforehand when communicating a UTF-8 enabled FTP server.

Under D2007 and earlier, the ADestEncoding parameter of ReadStringFromStream() is being set to nil. When it calls BytesToString() internally, ADestEncoding is being set to TIdTextEncoding.ASCII, causing non-ASCII characters to be lost before TIdFTP has a chance to parse the listing.

TIdIMAP4.GetResponse() should be re-written to utilize TIdTCPConnection's existing internal logic, and to validate the format of the server's replies, raising an exception if an unknown format is encountered.

Should TIdHTTP's ctProxy handling mirror its ctSSLProxy handling, just without the SSL portion?

TIdTrivialFTP.Put() opens the source file in exclusive access mode. It needs to open the file with less restrictive access.

RFC 2616 Section 8.2.2 recommends an HTTP client monitor the server for error replies while sending a request. This allows the server to stop the request before it is finished. TIdHTTP does not currently support that.

Validate TIdSysLogMessage against RFC 3164

Update TIdHTTP and TIdHTTPServer to support RFC 2616 Section 12

SMTP Service Extensions for Transmission of Large and Binary MIME Messages
https://tools.ietf.org/html/rfc3030

The current implementation was recently changed to escape "=" characters as "\=" in the "boundary" parameter of the "Content-Type" header for MIME emails. This appears to be wrong behavior. Need to re-review RFCs 822, 2045, and 2046 more carefully for proper escaping/quoting behavior.

Sometimes, clients do not send email addresses in a good format in the RCPT TO command. This can cause loss of data due to the current use of Fetch().

Here are some RCPT TO formats encountered:

RCPT TO:<test user <user@test .ca>>
RCPT TO:<test user [TAB] <user@test .ca>>
RCPT TO:<test user (user@test .ca)>
RCPT TO:<test user "user @test .ca">
RCPT TO:<test [email protected] (parameters)>
RCPT TO:[email protected] (parameters)
RCPT TO:[email protected]
RCPT TO:<test user@ domain.com (user@ domain .com)>

The Trivial FTP components currently use strings to transfer data around. This is broken when Unicode strings are used. They need to be re-written to transfer data using raw bytes instead. This way, there are no Ansi<->Unicode encoding issues to deal with.

TIdSchedulerOfThreadPool appears to still have the problems that have been discussed over the years.

April 2005:
http://newsgroups.cryer.info/atozedsoftware/indy.general/200504/0504253614.html

September 2005:
http://newsgroups.cryer.info/atozedsoftware/indy.general/200509/0509144041.html

October 2006:
http://delphi.newswhat.com/geoxml/forumhistorythread?groupname=borland.public.delphi.internet.winsock&[email protected]

Sometimes, Indy is used in a worker thread with other libraries that require message queue processing, such as ActiveX/COM objects. Currently, TIdAntiFreeze ignores message pump requests when calling in the context of worker threads. It could be updated to allow message pumping (not via TApplication.ProcessMessages(), though, as it is not thread-safe). Perhaps add a new property that is False by default for backwards compatibility, but can be set to True when needed. Or maybe add an event that users can use to perform their own message pumping as needed.

In IdZLibHeaders.pas, when STATICLOAD_ZLIB is defined, AVs occur in BCB5's compiler. The ZLib .OBJ files in the \Lib\Protocols folder are different than the .OBJ files in the \Lib\Protocols\ZLib folder. If all of the .OBJ files are deleted, ZLib is recompiled with BCB5's make.exe via the build.bat script, and the .OBJs moved into the \Lib\Protocols folder, the AVs go away but the compiler then complains about 3 unresolved external functions (inflateReset2(), inflateMark(), and inflateUndermine()) which do not exist in the ZLib source code that is currently checked in.

Add support for Simple FTP (RFC 913)