Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow unknown value data types for VALUE #674

Merged
merged 3 commits into from
Oct 22, 2024
Merged

Allow unknown value data types for VALUE #674

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9e72aca
Allow unknown value data types for VALUE
heiglandreas Sep 10, 2024
f7cef9c
Add tests for skipping unknown parameters
heiglandreas Oct 14, 2024
1f22f4a
Rework handling of values that are not recognized
heiglandreas Oct 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 16 additions & 9 deletions lib/Document.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -180,23 +180,30 @@ public function createProperty(string $name, $value = null, ?array $parameters =

$class = null;

// If a VALUE parameter is supplied, we have to use that
// According to https://datatracker.ietf.org/doc/html/rfc5545#section-3.2.20
// If the property's value is the default value type, then this
// parameter need not be specified. However, if the property's
// default value type is overridden by some other allowable value
// type, then this parameter MUST be specified.
if (!$valueType) {
$valueType = $parameters['VALUE'] ?? null;
}

if ($valueType) {
// The valueType argument comes first to figure out the correct
// class.
$class = $this->getClassNameForPropertyValue($valueType);
}

// If the value parameter is not set or set to something we do not recognize
// we do not attempt to interpret or parse the datass value as specified in
// https://datatracker.ietf.org/doc/html/rfc5545#section-3.2.20
// So when we so far did not get a class-name, we use the default for the property
if (is_null($class)) {
// If a VALUE parameter is supplied, we should use that.
if (isset($parameters['VALUE'])) {
$class = $this->getClassNameForPropertyValue($parameters['VALUE']);
if (is_null($class)) {
throw new InvalidDataException('Unsupported VALUE parameter for '.$name.' property. You supplied "'.$parameters['VALUE'].'"');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code used to be able to throw this exception if $parameters['VALUE'] had an invalid value (did not end up matching to a class).
Now, if $parameters['VALUE'] is not valid, the code will end up doing:
$class = $this->getClassNameForPropertyName($name);

That is, it will just ignore the invalid value, and use what has been passed in $name.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am surprised that no unit test has failed. I guess that there is not a unit test that covers the (now deleted) InvalidDataException

Copy link
Contributor Author

@heiglandreas heiglandreas Oct 15, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. As far as I see this part of RFC5545, Section 3.2.20 (Value Data Type)

Applications MUST preserve the value data for x-name and iana-token values that they don't recognize without attempting to interpret or parse the value data.

we need to allow to keep - but not interpret - VALUE information that we don't understand. That didn't work previously due to the Exception. That broke the whole process of interpretation.

The Exception has been introduced with c20acd7 about 8 years ago to have "A better error message for unsupported VALUE parameters." but even then there should have been no Exception as unsupported VALUE parameters IMO do not pose an error condition. They should not be interpreted, yes (what they are now), but not break the process but also be preserved for other tools to interpret that might be able to understand it.

That is the reason why the current process then falls back to the default value when "an invalid" - let's rephrase that to "a not recognized" - value is encountered.

}
} else {
$class = $this->getClassNameForPropertyName($name);
}
$class = $this->getClassNameForPropertyName($name);
}

if (is_null($parameters)) {
$parameters = [];
}
Expand Down
15 changes: 15 additions & 0 deletions tests/VObject/PropertyTest.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@
use PHPUnit\Framework\TestCase;
use Sabre\VObject\Component\VCalendar;
use Sabre\VObject\Component\VCard;
use Sabre\VObject\Property\ICalendar\DateTime;

class PropertyTest extends TestCase
{
Expand Down Expand Up @@ -391,4 +392,18 @@ public function testValidateBadEncodingVCard21(): void
self::assertEquals('ENCODING=B is not valid for this document type.', $result[0]['message']);
self::assertEquals(3, $result[0]['level']);
}

public function testUnknownValuesWillBeIgnored(): void
{
$cal = new VCalendar();
$property = $cal->createProperty('DTSTAMP', '20240101T000000Z', ['VALUE' => 'DATETIME']);

self::assertEquals("DTSTAMP;VALUE=DATETIME:20240101T000000Z\r\n", $property->serialize());

self::assertInstanceOf(DateTime::class, $property);
self::assertCount(1, $property->parameters());
self::assertInstanceOf(Parameter::class, $property->parameters['VALUE']);
self::assertEquals('VALUE', $property->parameters['VALUE']->name);
self::assertEquals('DATETIME', $property->parameters['VALUE']->getValue());
}
}