Problem with new LDIF file:// URL handling

[James A. Drenter]

Hello:

I've run into a problem when parsing an LDIF file that contains an entry
with a value that begins with a "<" (and probably a ":"), for example:

statusflag: <<AWAY>>

While this isn't valid for the strictest interpretation of the LDIF
specs/rfc2849 (the above should be base-64 encoded), neither is trying
to interpret the value as a URL when there is a space between the colon
and the "<" when you actually are trying to specify a URL, e.g.:

# Invalid URL line
myfile: < file:://myfilename

# Valid URL line
myfile:< file::/myfilename

This was pretty easy to make a bit more tolerant with a couple minor
changes to LDIF.pm, the diff output follows.

Regards,
James

*** LDIF.pm.orig 2004-07-01 18:48:38 -0400
--- LDIF.pm 2004-08-03 20:27:24 -0400
***************
*** 215,220 ****
--- 215,221 ----
while(@ldif) {
my $line = shift @ldif;
my $attr;
+ my $xattr;

if ($line eq "-") {
$entry->$modify($lastattr, \@values)
***************
*** 224,233 ****
last;
}

! $line =~ s/^([-;\w]+):\s*// and $attr = $1;

# base64 encoded attribute: decode it
! if ($line =~ s/^:\s*//) {
eval { require MIME::Base64 };
if ($@) {
$self->_error($@, @ldif);
--- 225,234 ----
last;
}

! $line =~ s/^([-;\w]+):([\<\:]?)\s*// and ($attr, $xattr) =
($1, $2);

# base64 encoded attribute: decode it
! if ($xattr eq ':') {
eval { require MIME::Base64 };
if ($@) {
$self->_error($@, @ldif);
***************
*** 236,242 ****
$line = MIME::Base64::decode($line);
}
# url attribute: read in file:// url, fail on others
! elsif ($line =~ s/^\<\s*(.*?)\s*$/$1/) {
$line = $self->_read_url_attribute($line, @ldif);
return if !defined($line);
}
--- 237,243 ----
$line = MIME::Base64::decode($line);
}
# url attribute: read in file:// url, fail on others
! elsif ($xattr eq '<' and $line =~ s/^(.*?)\s*$/$1/) {
$line = $self->_read_url_attribute($line, @ldif);
return if !defined($line);
}
***************
*** 266,276 ****
my $vals = [];
my $line;
my $attr;
foreach $line (@ldif) {
! $line =~ s/^([-;\w]+):\s*// && ($attr = $1) or next;

# base64 encoded attribute: decode it
! if ($line =~ s/^:\s*//) {
eval { require MIME::Base64 };
if ($@) {
$self->_error($@, @ldif);
--- 267,278 ----
my $vals = [];
my $line;
my $attr;
+ my $xattr;
foreach $line (@ldif) {
! $line =~ s/^([-;\w]+):([\<\:]?)\s*// && (($attr, $xattr) = ($1,
$2)) or next;

# base64 encoded attribute: decode it
! if ($xattr eq ':') {
eval { require MIME::Base64 };
if ($@) {
$self->_error($@, @ldif);
***************
*** 279,285 ****
$line = MIME::Base64::decode($line);
}
# url attribute: read in file:// url, fail on others
! elsif ($line =~ s/^\<\s*(.*?)\s*$/$1/) {
$line = $self->_read_url_attribute($line, @ldif);
return if !defined($line);
}
--- 281,287 ----
$line = MIME::Base64::decode($line);
}
# url attribute: read in file:// url, fail on others
! elsif ($xattr eq '<' and $line =~ s/^(.*?)\s*$/$1/) {
$line = $self->_read_url_attribute($line, @ldif);
return if !defined($line);
}

[Chris Ridd]

On 4/8/04 2:21 am, Drenter, James A. <james....@hp.com> wrote:

> Hello:
>
> I've run into a problem when parsing an LDIF file that contains an entry
> with a value that begins with a "<" (and probably a ":"), for example:
>
> statusflag: <<AWAY>>
>
> While this isn't valid for the strictest interpretation of the LDIF
> specs/rfc2849 (the above should be base-64 encoded), neither is trying
> to interpret the value as a URL when there is a space between the colon
> and the "<" when you actually are trying to specify a URL, e.g.:
>
> # Invalid URL line
> myfile: < file:://myfilename
>
> # Valid URL line
> myfile:< file::/myfilename
>
> This was pretty easy to make a bit more tolerant with a couple minor
> changes to LDIF.pm, the diff output follows.
>
> Regards,
> James

Thanks, I've just committed this.

Cheers,

Chris

[Graham Barr]

On 4 Aug 2004, at 02:21, Drenter, James A. wrote:
> Hello:
>
> I've run into a problem when parsing an LDIF file that contains an
> entry
> with a value that begins with a "<" (and probably a ":"), for example:
>
> statusflag: <<AWAY>>
>
> While this isn't valid for the strictest interpretation of the LDIF
> specs/rfc2849 (the above should be base-64 encoded), neither is trying
> to interpret the value as a URL when there is a space between the colon
> and the "<" when you actually are trying to specify a URL, e.g.:
>
> # Invalid URL line
> myfile: < file:://myfilename
>
> # Valid URL line
> myfile:< file::/myfilename
>
> This was pretty easy to make a bit more tolerant with a couple minor
> changes to LDIF.pm, the diff output follows.

An addition to the test suite to test this would be great if you could
write one.

Graham.