querter

Hello @Remy, // #409: Add ValueFromIndex[] property to TIdHeaderList // Open - rlebeau opened this issue on Apr 25, 2022 // URL: http://github.com/IndySockets/Indy/issues/409 // #408: TIdHTTP Response.RawHeaders returns wrong value when calling ValueFromIndex[index] // lloydbates opened this issue on Apr 25, 2022 // URL: h t t p s : / / github.com/IndySockets/Indy/issues/408 unit IdHeaderList; interface TIdHeaderList = class(TStringList) protected ... {String read from a position, Index} function GetValueFromIndex(var Index: Integer): string; {String inserts into a position, Index} procedure SetValueFromIndex(var Index: Integer; const Value: string); public ... property ValueFromIndex[var Index: Integer]: string read GetValueFromIndex write SetValueFromIndex; end; implementation ... function TIdHeaderList.GetValueFromIndex(var Index: Integer): string; begin Result := GetValueFromLine(Index); end; procedure TIdHeaderList.SetValueFromIndex(var Index: Integer; const Value: string); begin SetValue(Names[Index], Value); end; For the test, I deliberately set the fold length to 20 characters (very narrow) in order to get a lot of line breaks. File attachment:: Test-Routine.pas and detailed result list: FoldLength: 20 --------- --------- // Test FOR..TO ValueFromIndex[] FoldLines convert // #408; lloydbates commented on Apr 25, 2022 // h t t p s : / / github.com/IndySockets/Indy/issues/408#issue-1214406965 --------- 1 : Server OK "nginx" 2 : Date OK "Mon, 12 Feb 2024 21:10:33 GMT" 3 : Content-Type OK "text/html; charset=UTF-8" 6 : Transfer-Encoding OK "chunked" 8 : Connection OK "keep-alive" 10: Vary OK "Accept-Encoding" 11: Expires OK "-1" 12: Cache-Control OK "no-cache" 14: pragma OK "no-cache" 15: Set-Cookie OK "sid=cdd161af06b475cdd843009db42d4963; path=/" 18: X-Cache-Status OK "MISS" 19: Content-Language OK "de,at,ch" 21: Text1 OK "#Short-Text#" 22: Text2 OK "#Modifications - Ut wisi enim ad minim veniam, ..." 35: Text3 OK "#Long-Text - Ut wisi enim ad minim veniam, quis ..." 48: Text4 OK "#Short-Text - two#" --------- // Test FOR..TO ValueFromIndex[] FoldLines convert // #408: rlebeau commented on Apr 25, 2022 // h t t p s : / / github.com/IndySockets/Indy/issues/408#issuecomment-1108769280 --------- 1 : Server OK "nginx" 2 : Date OK "Mon, 12 Feb 2024 21:10:33 GMT" 3 : Content-Type OK "text/html; charset=UTF-8" 4 : Transfer-Encoding OK "chunked" 5 : Connection OK "keep-alive" 6 : Vary OK "Accept-Encoding" 7 : Expires OK "-1" 8 : Cache-Control OK "no-cache" 9 : pragma OK "no-cache" 10: Set-Cookie OK "sid=cdd161af06b475cdd843009db42d4963; path=/" 11: X-Cache-Status OK "MISS" 12: Content-Language OK "de,at,ch" 13: Text1 OK "#Short-Text#" 14: Text2 OK "#Modifications - Ut wisi enim ad minim veniam, quis ..." 15: Text3 OK "#Long-Text - Ut wisi enim ad minim veniam, quis nostrud ..." 16: Text4 OK "#Short-Text - two#" --------- HeaderList_ValueFromIndex_Console.dpr result.txt

Hello INDY users, hello Remy, After a server update on the part of the hoster, we were no longer able to read the validity of the cert (NotAfter: TDateTime) from an FTPES connection with INDY10 #520. It turned out that the ftp server now sends the NotAfter date with a four-digit year (2051). INDY10 cannot handle this and terminates with an EConvertError. Could a possible fundamental cause of the problem be that <=2049 UTC time and >=2050 generalised time is used? "RFC 5280:May 2008 - Internet X.509" 4.1.2.5. Validity The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. The field is represented as a SEQUENCE of two dates: the date on which the certificate validity period begins (notBefore) and the date on which the certificate validity period ends (notAfter). Both notBefore and notAfter may be encoded as UTCTime or GeneralizedTime. CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime. Indy10 (D7) TIdX509.notBefore with four digits for the year has failed. and TIdX509.notAfter with four digits for the year has failed. GoDaddy / Domainfactory (DE) new self-signed certificate has date "Not after" > 2050 and the ftp server sends new date in format GeneralizedTime with four digits for the year. (TIdX509.DisplayInfo.Text) Certificate: Data: Version: 3 (0x2) Serial Number: Signature Algorithm: sha256WithRSAEncryption Issuer: C=DE, ST=Bayern, L=Muenchen, O=ispgateway, CN=webserver.ispgateway.de Validity Not Before: Dec 12 05:43:54 2023 GMT Not After : Apr 29 05:43:54 2051 GMT ... The ftp server send the data-format: Not Before: 231212054354Z Not After : 20510429054354Z TIdX509.notBefore can only decode two digits for the year YYMMDDHHMMSS. TIdX509.notAfter can only decode two digits for the year YYMMDDHHMMSS. TIdX509.notBefore: OK = 12.12.2023 05:43:54 TIdX509.notAfter: FAIL = EConvertError and excepted. in IdSSLOpenSSL.pas: -> TIdX509 property notAfter -> call function RnotAfter -> call function UTCTime2DateTime() -> call function UTC_Time_Decode() ! failed; In IdSSLOpenSSLHeader.pas the function UTC_Time_Decode() give missmatch back. The workaround can now decode both four-digit and two-digit years. TIdX509.notBefore now can decode two and four digits for the year YYMMDDHHMMSS / YYYYMMDDHHMMSS. TIdX509.notAfter now can decode two and four digits for the year YYMMDDHHMMSS / YYYYMMDDHHMMSS. TIdX509.notBefore: OK = 12.12.2023 05:43:54 TIdX509.notAfter: OK = 29.04.2051 05:43:54 And in UTC_Time_Decode() there are two more small errors in the TZ check. I have only written further details and workaround in the "German section" so far. Delphi-Praxis (DE): SSL Cert gültig bis 2051: Indy10 (D7) TIdX509.notAfter = EConvertError Please, can any of you help me? Greetings, qwerter