Jump to content

Recommended Posts

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
 

Share this post


Link to post

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 by lindenR

Share this post


Link to post

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

 

Share this post


Link to post

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

 

Share this post


Link to post

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 by lindenR
EncodeDate

Share this post


Link to post
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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×