Replies: 2 comments
|
I don't quite see the bug i'm afraid, the logic seems to follow the documentation in the precedence order it is described. https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Content-negotiation |
0 replies
|
I insist on my initial point, though I'll break it down in a explicit example: This works as expected: get '/' => { format => "txt" } => sub($c) {
$c->respond_to(
html => {},
json => {},
any => { format => "txt"}
);
} => "index";This one below completely breaks content negotiation (replies everything with the default format and ignores the get '/' => { format => "txt" } => sub($c) {
$c->respond_to(
txt => {},
html => {},
json => {},
any => { format => "txt" },
);
} => "index";The simple fact that the default format is included inside the So I don't think this subtle change is the expected behavior. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I'm trying to change the default response type of an endpoint to
text/plain, so that when a user runscurl /and the app receives the headerAccept: */*it will reply with atxt, not html.A simplified sample code of how I'm trying it:
The above looks right to me. But it completely breaks content negotiation, replying all requests with the default format. For example, when running:
$ ./app.pl get -H 'Accept: text/html' /$ ./app.pl get -H 'Accept: application/json' /But if I remove the
txt => {}line (line 4) fromrespond_to(), lettingtext/plainbe catched by theanyformat, it works as expected (i.e. content negotiation throughAcceptheader works, and it correctly fallsback unknowns totxtformat). If I omit theanyformat it replies with204 No Contentfortxtand other formats (other than the ones listed inrespond_to()).So I believe this is a subtle bug in content negotiation, the fact that when you explicitly specify a default format and include it in a
respond_to()method call, it breaks content negotiation through theAcceptheader.This same problem happens when the default format is explicitly specified as
html, e.g.:get '/' => { format => "html" } => sub { ... };so it's not the case of changing the response format to something other than
html.All reactions