rlebeau on FTP-Active-Mode-Fix
rlebeau on master
#310 Updating TIdFTP.Login() to… (compare)
rlebeau on master
#308 Updating .bat files for De… (compare)
we currently using Explicit option, and here is the code:
however I found that even I remove line 2, it still works correctly. I checked the code for Authenticate, it calls StartTLS. Does TIdSMTP.Connect also call StartTLS as well somewhere?
Hi, Remy. After migration from Indy9 to Indy10 i found one more issue:
our web server always requires Content-Length in header of HTTP Post method. It doesn't matter whether ContentStream is assigned or not.
In Indy10 code i see that in case when ASource is not assigned then header is not added:
if Assigned(ARequest.Source) then begin
ARequest.ContentLength := ARequest.Source.Size;
end else begin
ARequest.ContentLength := -1; => leads to omitting of 'Content-Length'
For this moment i have workaround via adding 'Content-Length' to CustomHeaders (value is '0', works great!). Moreover, seems Indy9 always added 'Content-Length'!
Please, consider adding 'Content-Length' always in library as well. At least i see it is a widespread issue:
Hi, Remy. I wonder, what Indy10 means by 'Content-Length' for TIdMultipartFormDataStream?
I have next code:
AMultiPartFormData := TIdMultipartFormDataStream.Create; // Size=-1, OK
AField := AMultiPartFormData.AddFormField(AId, '', '', 'application/octet-stream'); // size = 222, might be OK
DataStream.CopyFrom(AStream, ALength); // ALength = 100500 bytes
ADataStream.Position := 0;
AField.FieldStream := ADataStream; // after that size became even smaller 220 bytes! why? i expect to see it >= ALength
moreover i must also sent 'Content-MD5' header and have no idea what should be there... In previous version of code with Alcinoe library we had there
CalculateMD5ForStream(ADataStream); and everything works well!
@rlebeau, i've just checked change of size via Debug Watch . As i said above it happens only in case when my stream position is at the end.
I have another question, my HTTP protocol has KeepAlive=True and i see that in this case no disconnection happens:
if not Response.KeepAlive then begin
// TODO: do not disconnect if hoNoReadMultipartMIME is in effect
// TODO: do not disconnect if hoNoReadChunked is in effect
but i wonder whether is it a good idea to disconnect in case when socket error occurs? E.g. 'connection reset by peer'?