Skip Menu |
 

This queue is for tickets about the Catalyst-Runtime CPAN distribution.

Report information
The Basics
Id: 123636
Status: open
Priority: 0/
Queue: Catalyst-Runtime

People
Owner: Nobody in particular
Requestors: rrwo [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Head middleware conflicts with ETag middleware
Date: Wed, 15 Nov 2017 13:57:42 +0000
To: bug-Catalyst-Runtime [...] rt.cpan.org
From: Robert Rothenberg <rrwo [...] cpan.org>
Download (untitled) / with headers
text/plain 1005b
By including the Head middleware in the defaults, this conflicts with the ETag middleware. The result is that HEAD requests return different ETags than GET requests. I've been able to work around the issue in a Catalyst app with this: around default_middleware => sub { my $next = shift; my $self = shift; my @mw = grep { !$_->isa('Plack::Middleware::Head') } $self->$next(@_); return @mw; }; and then manually adding the middleware in the PSGI file: enable "Plack::Middleware::Head"; enable "Plack::Middleware::ConditionalGET"; enable "Plack::Middleware::ETag"; That feels like an awful hack. I'm not sure what a better solution is. The easiest fix is to make it easier to modify the default middleware in the configuration. I think a better long-term solution for Catalyst is to only load middleware that is needed, such as the stash middleware. The recommended defaults can be loaded by a plugin, or maybe multiple plugins.
Download (untitled) / with headers
text/plain 423b
On 2017-11-15 05:57:57, RRWO wrote: Show quoted text
> By including the Head middleware in the defaults, this conflicts with > the > ETag middleware. The result is that HEAD requests return different > ETags > than GET requests.
Is this a catalyst-specific problem? Or does it also happen with a bare-bones PSGI application run with 'plackup'? (i.e. the authors of the respective middlewares should probably be alerted and get involved.)
Subject: Re: [rt.cpan.org #123636] Head middleware conflicts with ETag middleware
Date: Wed, 15 Nov 2017 22:08:56 +0000
To: bug-Catalyst-Runtime [...] rt.cpan.org
From: Robert Rothenberg <rrwo [...] cpan.org>
Download (untitled) / with headers
text/plain 541b
On 15/11/17 17:57, Karen Etheridge via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=123636 > > > On 2017-11-15 05:57:57, RRWO wrote:
>> By including the Head middleware in the defaults, this conflicts with >> the >> ETag middleware. The result is that HEAD requests return different >> ETags >> than GET requests.
> > Is this a catalyst-specific problem?
Yes. Catalyst loads some middleware by default, without an obvious way to control the order of the layers. The middlewares in question are working as they should.
Subject: Re: [rt.cpan.org #123636] Head middleware conflicts with ETag middleware
Date: Thu, 16 Nov 2017 10:37:54 +0000
To: bug-Catalyst-Runtime [...] rt.cpan.org
From: Robert Rothenberg <rrwo [...] cpan.org>
Download (untitled) / with headers
text/plain 427b
I think the heading for this bug is too specific to what the actual problem is. The actual problem is that there's very little control of the default middleware that Catalyst loads. I cannot remove something, or change the order or even configuration (e.g. enable_if clauses). I think the simplest solution is to have a plugin that loads these defaults, which devs can opt not to use, if they want finer control over it.
Download (untitled) / with headers
text/plain 1.1k
On Thu Nov 16 05:38:12 2017, RRWO wrote: Show quoted text
> I think the heading for this bug is too specific to what the actual > problem is. > > The actual problem is that there's very little control of the default > middleware that Catalyst loads. I cannot remove something, or change > the > order or even configuration (e.g. enable_if clauses). > > I think the simplest solution is to have a plugin that loads these > defaults, > which devs can opt not to use, if they want finer control over it.
I'm happy to get a patch that would give people control over the default middleware, however you are not required to use it (I don't). It was really a relic of the effort than went into making the PSGI port as backward compatible as possible with at the time applications. Generally I just skip it and add in the bits I want. If you really need more control that is what I'd recommend. I'll leave this open for now, but I personally don't have time to write a patch, given the workaround available. I will however be happy to get one from anyone that wants to give it :) Or even a doc patch on how to workaround when needed.. jnap


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.