Filter list of acceptable headers; use default if the client accepts everything

[mlambley]

Added a priorities member variable, which allows the dev to filter the list of acceptable headers.

Usage:

//Code
Middleware::FormatNegotiator()
    ->setPriorities(['json', 'zip'])
    ->defaultFormat('json')

//Request header
Accept: application/pdf, application/zip

//Result: 
FormatNegotiator::getFormat($request) === "zip"

getFromHeader will return null if the accept header is either missing, or set to accept everything. This will allow the default to be used instead.

Usage:

//Code
Middleware::FormatNegotiator()
    ->defaultFormat('json')

//Request header
Accept: */*

//Result: 
FormatNegotiator::getFormat($request) === "json"

[oscarotero]

The PSR-15 version of this middeware accept a list of formats in the constructor:
https://github.com/middlewares/negotiation#contenttype
This allows to define not only the formats but also the priority. I think it's a more simple and elegant solution.

[mlambley]

Hi Oscar, I might just use the PSR-15 one instead.

I've just updated this PR to make $priorities a constructor parameter, bringing that newer version's functionality into this version. Do you still want it?

[mlambley]

Quick note: I've given up on trying to retrofit PSR-15 middlewares into Slim (the framework I'm using). Apparently support will be in a later version. So I will need to use this PSR-7 FormatNegotiator.

[oscarotero]

Hi, @mlambley
What I meant was the constructor argument were the available formats, not the priorities. For example, if you only want to support json:

Middleware::FormatNegotiator([
    'json' => [['json'], ['application/json', 'text/json', 'application/x-json']],
])

This prevent the situation where you customize the desired priorities but the formats are not available, which would be confused.
In addition to that, the defaultFormat could be always the first format provided.

[mlambley]

I figure that you would want to keep the existing addFormat and defaultFormat functions, to not introduce a breaking change, even though the functionality is replicated.

I have not set the default format to be the first item in the list, on the assumption that we will not be removing the defaultFormat function.

[oscarotero]

Yes, I don't want to introduce breaking changes here. addFormat and defaultFormat functions will continue to exist. What I suggested is:

• Modify __construct to include the desired formats. The first value of the array is the default value. Example:

  $this->defaultFormat = key($this->formats);

  Because the first value of the default formats is html, the default value is html, as it works now. So, no breaking changes here.
• addFormat just add more formats at the end of the array. Nothing changes here
• defaultFormat just change the value of the default format. Additionally, I think the default format should be moved to the first place. For example, for json:

  $default = $this->formats['json'];
  $this->formats = ['json' => $default] + $this->formats;

  In this way, * or */* would return the first format (the default) by the headers negotiation.

[mlambley]

Hi Oscar, I've introduced an option for it to generate a 406 Not Acceptable response in order for it to work with my server. Please let me know if this, and the other changes you requested, are ok.

I'm hoping that you won't consider this change to be breaking, since the behaviour of setting default to null is currently undefined.

[oscarotero]

I think it's good. In fact, I have a similar feature in the PSR-15 version
Thanks 👍