Content type matching problem with LinkedIn #35
Conversation
I've recently encountered a problem using the LinkedIn configuration for this plugin. The rule for matching the content type should look like this: m!^(application/json|text/javascript)(;\s*charset=\S+)?$! because in the LinkedIn case there is no space between the content type and the charset definition. Also maybe you should include an else statement for this rule in case is not matched.
|
How about we allow overriding the regex in each provider's configuration hashref? So that we don't "contaminate" the main regex too much. |
|
Supporting overrides in the provider hashref seems like the best solution Marcus On Mon Nov 10 2014 at 3:40:37 PM Alexander Karelas notifications@github.com
|
|
But the solution proposed by @ratcristian should work just fine. It's actually completing the original expression. |
|
After thinking it through, I'm leaning towards considering this a bugfix of the original regex, as @marghidanu suggests. I guess we can also add support for overriding it later if anyone has a valid use case for that. |
Content type matching problem with LinkedIn
|
Will this result in a CPAN release? |
I've recently encountered a problem using the LinkedIn configuration for this plugin. The rule for matching the content type should look like this:
m!^(application/json|text/javascript)(;\s*charset=\S+)?$!
because in the LinkedIn case there is no space between the content type and the charset definition. Also maybe you should include an else statement for this rule in case is not matched.