After deploying the negotiation library as part of FriendsOfSymfony/FOSRestBundle version 2.0.0 we started to get

E_WARNING: array_map(): An error occurred while invoking the map callback

from Negotiation\AbstractNegotiator::getBest() (27 or 28). I assume this happens because Negotiation\Accept::__construct() may throw an exception when constructed with an invalid value. This in turn seems to trigger PHP bug #55416 causing a warning to be emitted.

I don't know which exact value seems to cause this problem as the issue is not reproducible and only happens sparsely on our live servers - most often with some Android phones.

Can this part be rewritten somehow to circumvent PHP bug #55416? Or can the logic be implemented a little bit more tolerant to weird values coming in from web clients?

When creating a RESTful API you'd like to be able to have a clear overview and simple configuration of which versions you (will) accept / are able to provide. In your API code you'd like to keep your versions separated in a nice way. This implementation is the result of my approach to give every version of a RESTful API their own namespace under a particular directory. This way the directory containing that namespace can be 'closed' for modification to freeze an API version and keep all code for a particular version in one place to prevent mistakes / 'fixes' which lead to broken versions.

I'm not sure if this is an issue with my install or something else that I can help resolve. I am occasionally receiving the following error in this class:

PHP Notice: Undefined offset: 1 in /../vendor/willdurand/negotiation/src/Negotiation/Negotiator.php on line 161

I am using Symfony 2.4.1 with FOSRestBundle 0.13.0.

Thanks for the help!

Related with: https://github.com/FriendsOfSymfony/FOSRestBundle/issues/682

Configuration read from /var/www/Negotiation/phpunit.xml.dist

............................F.................................... 65 / 98 ( 66%)
.................................

Time: 79 ms, Memory: 4.00Mb

There was 1 failure:

1) Negotiation\Tests\FormatNegotiatorTest::testGetBest with data set #24 ('image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, */*', array('text/html', 'application/xhtml+xml', '*/*'), 'text/html')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'text/html'
+'image/jpeg'

/var/www/Negotiation/tests/Negotiation/Tests/FormatNegotiatorTest.php:43

FAILURES!
Tests: 98, Assertions: 231, Failures: 1.

Given this code:

$negotiator = new \Negotiation\LanguageNegotiator(); $language = $negotiator->getBest('en-US', array('fi','sv','en'));
echo $language->getValue() . "\n";

the result is "en-US", so the returned result is not among the given priorities.

I guess this is sort of allowed by RFC2616, as it doesn't consider an available generic language resource (e.g. "en") to be a match for a requested variant (e.g. "en-US"). But I think it is rather unfortunate that getBest() returns a result that is not even available on the server...

This is due to this line in Negotiator.php setting the default for $best: $best = reset($acceptHeaders); and when all matching fails, this is what eventually gets returned by getBest().

I think the correct response in this case would be either "en" (though it sort of violates RFC2616), or NULL.

If you agree with my reasoning I can produce a pull request implementing the chosen solution.

The biggest change to support PHP 8 is the Match class which fails due to the new match expression (match is now a reserved keyword).

This PR also adds PHP nightly on Travis in order to run the unit tests on PHP 8. This requires an upgrade on PHPUnit to 9.3-dev which is the only version to support PHP 8. But this means PHP 7.0 - 7.2 support needs to be dropped (7.2 is in security-fix for the next 3 months only).

An alternative option to keep support for PHP < 7.3 is to install different PHPUnit versions in Travis for each build. If you want to go that route then I'll update the PR accordingly.

When youve only selected a single language in your browser (I tried it in Firefox 68) the library will not detect the language. The header sent is:

Accept-Language: de-DE

silently skip invalid header values coming in from a client

instead of throwing exceptions on invalid headers from clients, the new code silently skips these header values and continues to parse the header for a best match

Commit 4e4802509d599d7be6cef919c5e79b3324cb34b4 silently skips invalid headers. I want this library to catch invalid headers so I can 406. It seems silly that I should have to parse the headers again to determine if they are invalid when the library is already doing this.

What do you think about reversing this change or adding a flag to getBest() to enable/disable this? I'm willing to implement this change.

Fixes #93. If there are no wildcard segments in either the subtype or + segment of either the Accept header or priority, do not attempt to compare them.

Adds more tests for #92 as well, using * subtypes in both the Accept header and priorities, to validate that different combinations work as expected.

Hi. From the google spiders, I get the following Accept header: text/html, image/gif, image/jpeg, *; q=0.2, */*; q=0.2 And this generate the following exception:

Negotiation\\Exception\\InvalidMediaType(code: 0):  at /vendor/willdurand/negotiation/src/Negotiation/Accept.php:20)

I think the problem is the first * that should be */*. Maybe this library should treat * as equivalent to */*?

This PR fixes #89 - IDEs will not complain about the use of type hints or object inheritance any more.

I have used PHPStan set to level 5 checks to expose any ambiguous/incorrect uses of type hinting. My IDE is happy now!

Currently passing in an accept header equals */* does not work. It tells that there's no match and EncodingNegotiator::getBest() returns null instead it should return the highest prioritized available content type.

$negotiator = new EncodingNegotiator();
$mediaType = $negotiator->getBest('*/*', ['application/json']);
var_dump($mediaType); // -> null, but should be 'application/json'

Hi all,

This was a interesting case encountered using the Microsoft Edge (41.16299.15.0) browser, which sends the following headers by default.

Accept: text/html, application/xhtml+xml, image/jxr, */*

When the priorities are prioritised with application/json, text/html; then the Content Negotiation will prefer the application/json response type; this should clearly prefer text/html based on the headers send by Edge.

I worked around the issue by changing the priority from application/json, text/html => text/html, application/json. But I thought it a good idea to flag this issue.

I've written some tests which expose this behaviour, the following is the (invalid) 'passing' test.

array(
    array(new Accept('text/html'), new Accept('application/xhtml+xml'), new Accept('image/jxr'), new Accept('*/*')),
    array(new Accept('application/json'), new Accept('text/html')),
    array(
        new Match(1.0, 0, 0),   // application/json
        new Match(1.0, 110, 1), // text/html
        new Match(1.0, 0, 1),   // */*
    )
)

This seems to be caused by the index, but I am not exactly sure what the correct fix would be, hense the lack of a PR. My best guess is that application/xhtml+xml should not match application/json in any way, as they are radically different.

To get offline source inspection (phan, Php Storm, etc.) currently I have to manually type-hint the return-type of getBest() inline - for example:

            $negotiator = new Negotiator();

            /** @var Accept $result */
            $result = $negotiator->getBest(
                $request->getHeaderLine("Accept"),
                ["application/json", "text/html"]
            );

            if ($result->getValue() === "application/json") {
                // ...
            }

Without the @var annotation, the if-statement will fail inspection, because the return-type of getBest() was declared as AcceptHeader rather than Accept, which appears to be the actual return-type.

What's the purpose of the empty AcceptHeader interface?

Given a list of languages like:

['en-US' => '...', 'en-UK' => '....']

And a language string of:

en-US, *

I get the value for en-UK using getBest and based on my (admittedly new) reading of the RFC suggests that I should get the 'en-US' value since it is listed first and they have the same quality factor. (Common sense suggests that is the better value.)

Switching the accept string to be en-US, *;q=0 resolves the matter but seems either incorrect or at least unnecessary.

Am I doing something wrong or is this a bug? It looked similar to some of the other open issues, but not quite the same. It also wasn't a problem in the 1.x release series.