Encode Date

[lindenR 0]

The functionality added in 6.81 in 

Added more header response properties: RespDateDT,
                     RespLastModDT, RespExpires, RespCacheControl.

 

Uses EncodeDate rather than TryEncodeDate in the utility function

function RFC1123_StrToDate(aDate : String; UseTZ: Boolean = False) : TDateTime;

 

would it not be more preferable to use the same functionality as used by 

function RFC3339_StrToDate(aDate: String; UseTZ: Boolean = False): TDateTime;

 

and avoid response lines like

 

'Expires: 0'

 

triggering unnecessary EConvertExceptions

 

Linden ROTH
 

[lindenR 0]

here is the code for a RFC1123_TryStrToDate

with some options 

 

{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *}
{ RFC1123 5.2.14 redefine RFC822 Section 5.                                 }
{ V8.62 optionally process time zone and convert to local time }
{Linden ROTH modified to not raise exceptions on encode invalid Dates/Times}
function RFC1123_TryStrToDate(aDate : String; UseTZ: Boolean = False) : TDateTime;
var
    Year, Month, Day : Word;
    Hour, Min,   Sec : Word;
    tzvalue: Integer;
    sign: String;
    tmpTime : TDateTime;
begin
    if Trim( ADate ) = '0' then //or even just length < 13 
      begin
        result := 0;
        exit;
      end;

    { Fri, 30 Jul 2004 10:10:35 GMT }
    { Tue, 11 Jun 2019 12:24:13 +0100 }
    Day    := StrToIntDef(Copy(aDate, 6, 2), 0);
    Month  := (Pos(Copy(aDate, 9, 3), RFC1123_StrMonth) + 2) div 3;
    Year   := StrToIntDef(Copy(aDate, 13, 4), 0);
    Hour   := StrToIntDef(Copy(aDate, 18, 2), 0);
    Min    := StrToIntDef(Copy(aDate, 21, 2), 0);
    Sec    := StrToIntDef(Copy(aDate, 24, 2), 0);
    if not TryEncodeDate(Year, Month, Day, Result ) then
      begin
        result := 0;
        exit;
      end;
    if not TryEncodeTime(Hour, Min, Sec, 0, tmpTime ) then
      exit;
//or - to 0 complete result
//      begin
//        result := 0;
//        exit;
//      end;
//or - to ignore bad time but proceed
//      tmpTime := 0;
    Result := Result + tmpTime;

{ V8.62 check for time zone, GMT, +0700, -1000, -0330 }
    if NOT UseTZ then Exit;
    if Length(aDate) < 29 then Exit ;  // no time zone
    sign := aDate [27];
    if (sign = '-') or (sign = '+') then begin // ignore GMT/UTC
        tzvalue := StrToIntDef(copy (aDate, 28, 2), 0) * 60;
        if (aDate [30] = '3') then
            tzvalue := tzvalue + 30;
        if sign = '-' then
            Result := Result + (tzvalue / MinutesPerDay)
        else
            Result := Result - (tzvalue / MinutesPerDay);
    end;
    Result := Result - (IcsGetLocalTimeZoneBias / MinutesPerDay);
end;

Edited October 21, 2019 by lindenR

[Angus Robertson 574]

Which component or unit are you referring to?

 

Angus

 

[lindenR 0]

Sorry unit that effects me is

 

OverbyteIcsHttpProt;

 

at line 3340

        else if Field = 'expires' then begin     { V8.61 }
            try
                FRespExpires := RFC1123_StrToDate(Data) ;
            except
                FRespExpires := 0 ;
            end ;
        end
 

Fix that I've suggested is in OverbyteIcsUtils; at line 1370ish

 

[Angus Robertson 574]

Thanks, RFC1123_StrToDate is a very old function that probably precedes TryEncodeTime being added to Delphi, and has worked fine ever since. 

 

Using it would avoid an internal exception if the web server returns bad date headers, which is very rare, and you'd get a date at least if the time was invalid.  I'll look into it.

 

Angus

 

[lindenR 0]

The Data that is firing the exception is

 

Expires: 0

 

I have observed this in commercial web data - Okta / Azure - in my case I'm getting 6 exceptions in a OAuth2 + Data call 

 

so even a check for data length before the call would negate exception on "normal" data

 

BTW I'm more concerned with the EncodeDate as that the cause of the exception (with 0 or -1 style data) ... I think that if the data was valid for date the time would normally be OK as you say headers are rarely invalid

 

Edited October 23, 2019 by lindenR
EncodeDate

[Angus Robertson 574]

i have made RFC1123_StrToDate more robust with error handling, it will be in SVN later today with other changes.

 

Angus

 

[lindenR 0]

18 hours ago, Angus Robertson said:

i have made RFC1123_StrToDate more robust with error handling, it will be in SVN later today with other changes.

 

Perfect ... thanks