Problem/Motivation
https://tools.ietf.org/html/rfc7231#section-6.5.6 says
6.5.6. 406 Not Acceptable
The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 5.3), and the server
is unwilling to supply a default representation.
The server SHOULD generate a payload containing a list of available
representation characteristics and corresponding resource identifiers
from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in
Section 6.4.1.
… i.e. there's no standardized way to communicate the list of acceptable formats. Also see https://httpstatuses.com/300. See https://github.com/Respect/Rest/issues/39 for an example discussion of a project attempting to implement this … and getting sucked into an endless discussion. That being said, I think we should do something until it's standardized.
Proposed resolution
Update \Drupal\Core\Routing\RequestFormatRouteFilter
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
None.
Comments
Comment #2
wim leersComment #3
wim leersComment #5
wim leersThis should be green.
Comment #6
wim leersAnd here's minimal integration test coverage. Once #2854543: NegotiationMiddleware calls $request->setRequestFormat('html') when there is no _format request parameter, but shouldn't is in, it can become nicer/better.
Comment #7
mpdonadioOn iPad, so can’t easily quote the code or run tests, but don’t see why the change to UnroutedUrlAssembler is needed? The change to RequestFormatRouteFilter looks *really* nice.
Comment #8
wim leersThanks for the review!
Because
Url::fromUri('http://example.com/foo?_format=foobar', ['query' => ['_format' => 'json']])->toString(TRUE)->getGeneratedUrl()returns this in HEAD:
the changes fix a bug so that it returns what you'd expect instead:
(Yes, that should be moved into a separate issue probably.)
Comment #9
borisson_#8, I don't see the difference in both examples here.
So, is this thing is content type or a mime type? I think we should rename the
$content_typevariable here to$mime_type.This should get some documentation.
Comment #10
wim leers🤐😳 — fixed!
Agreed with both of your review points. But I first want sign-off on the approach, it's no time to nitpick yet!
Comment #11
borisson_I think I agree with your assesment in #8, that the changes to the unrouted url assembler should be moved to a different issue. It's a different bug and is probably going to require more discussion than this bugfix.
I'm not sure if adding this as an additional header is the best solution, maybe a response with this in
_links. However, that might be very hal specific. I see that is one of the suggestions in the github issue as well: https://github.com/Respect/Rest/issues/39#issuecomment-6495329Comment #12
mpdonadioCreated #2955685: Unrouted URLs cannot have have overridden query or fragments
Comment #13
wim leers#11:
Exactly. That's a non-option because it only makes sense for HAL normalizations. And this is decidedly not HAL-specific.
#12: thank you for creating that issue! ❤️
Comment #14
wim leersLet's make it clear this is blocked on #2955685: Unrouted URLs cannot have have overridden query or fragments.
Comment #15
wim leers#2955685: Unrouted URLs cannot have have overridden query or fragments landed!
Comment #16
wim leersA simple rebase that removes all changes that landed in #2955685: Unrouted URLs cannot have have overridden query or fragments was all we needed!
Comment #17
wim leersMissing comment. Fixed.
Better yet: #2854543: NegotiationMiddleware calls $request->setRequestFormat('html') when there is no _format request parameter, but shouldn't added very similar logic … so we can now just extract that existing logic into a separate function instead!
Comment #18
dawehnerI'm curious whether we could test for the formats as well here.
Comment #19
wim leersDone!
Comment #20
borisson_#19 fixes #18 and I couldn't find anything else either. The patch has good testcoverage and it should make everyone's lives easier.
Comment #21
alexpottCommitted 8ce2a3e and pushed to 8.6.x. Thanks!
Credited @borisson_ and @dawehner for reviews.