-
Notifications
You must be signed in to change notification settings - Fork 62
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.
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
E_WARNING: array_map(): An error occurred while invoking the map callback #81
Comments
Hi @sgehrig, that's definitely not cool, and I am sorry for that. There are only two occurences of the Negotiation/src/Negotiation/AbstractNegotiator.php Lines 27 to 28 in 5154ac7
|
@sgehrig: which PHP version do you have in prod? |
Currently it's still an Ubuntu 14.04LTS with PHP Oh and thanks for getting into that so quickly :-) |
Thank you. That looks tricky because this "bug" should be covered by a test case (here). Which negotiator are you using in your code? |
FriendsOfSymfony/FOSRestBundle uses a Unfortunately
But still, in the end some values are fed into |
It is a bug in Negotiation, not in FOSRestBundle IMO |
@willdurand: Updated my comment - sometimes I should think to the end before writing a comment ;-) |
PHP version is |
@sgehrig actually, they do have a |
Maybe the second argument of |
Could it be that PHPUnit interferes here in the sense that the PHPUnit error handler somehow mitigates the problem with PHP bug #55416? |
I don't know. PHPUnit keeps track of the |
If I disable these in the
I'm getting
In fact it's the |
That is interesting 😋 |
Great. I fixed the issue I guess. |
I hate it when I don't know why things are getting weird, so I dug around PHPUnit a little bit. I assume that's the real issue behind this test succeeding even though it should fail: |
Alright, so I pushed a fix for the warning in #82. It does solve the That being said, question is: should Negotiation handle/accept incorrect IMO, it should enforce correct headers, otherwise it would not make much sense. I believe that the decision must be left to the caller of the lib, e.g., FOSRestBundle. Their negotiator should catch the exceptions, and deal with them. For example, if the exception thrown is of type WDYT? |
That's good question though. The purpose of the So in case the header coming in from a client contains incorrect values I personally would assume that The case is different for the list of prioritized options. Here I'd expect an exception to be thrown if there's a malformed value because then the system's negotiation base is wrong. |
But I think, changing this will lead to a BC break - but at least it'll resolve the main issue very quickly ;-) |
Agreed. |
What you said here makes perfectly sense. I am wondering how to fix the whole thing, because it might not be a BC break actually, but a bug fix. Would you want to work on a fix based on my PR? I think it only needs a try/catch in the loop of the header string. |
Sure. Will take a look on Tuesday. |
BC break? - Fix for issue #81 - silently skip invalid header values coming in from clients
Just released Negotiation 2.0.3 |
Thanks for your quick help! |
After deploying the negotiation library as part of FriendsOfSymfony/FOSRestBundle version 2.0.0 we started to get
from
Negotiation\AbstractNegotiator::getBest()
(27 or 28). I assume this happens becauseNegotiation\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?
The text was updated successfully, but these errors were encountered: