Hey,
So when I was looking at this it seemed to me the order of the middleware stack
was correct, so I wrote a quick test case:
https://github.com/perl-catalyst/catalyst-runtime/blob/master/t/head_middleware.t
and it does seem to me that this works as desired (if you have an action that
provides a body content, but hit it with a HEAD request, then the body gets
removed by the Head middleware but not before the ContentLength middleware has
time to calculate the missing content length header. Here's the current
middleware stack for the most recent release of Catalyst:
Plack::Middleware::HTTPExceptions-new,
Plack::Middleware::RemoveRedundantBody-new,
Plack::Middleware::FixMissingBodyInRedirect-new,
Plack::Middleware::ContentLength-new,
Plack::Middleware::MethodOverride-new,
Plack::Middleware::Head-new,
Middleware handles a response from the top down (and the request comes the
other way, from the bottom up). In fact I can make my test case fail by
reversing the order of the Head and ContentLength middleware, so I am sure this
is the case. I'm adding this test case to the next release of catalyst to help
and to help prevent regressions.
jnap
On Thursday, May 1, 2014 6:01 PM, John Napiorkowski jjn1...@yahoo.com wrote:
Content Length auto detection was moved from Catalyst core to middleware in a
recent build of Catalyst. Its likely that the view you are using isn't
bothering to set the length and the middleware is failing to provide it
properly since the Head middleware has already removed it.
Since the content length SHOULD be provided for the case of HEAD, could you
provide a test case and lets see if shuffling the order of the registered
middleware fixes this problem?
There's a method called 'registered_middlewares' in Catalyst.pm that dictates
the order. If you can provide me a failing test case in the repo
(https://github.com/perl-catalyst/catalyst-runtime) I am sure I could fix it
pretty quick.
Sorry for the slow response, BTW, there's also middleware for the md5
Plack::Middleware::ContentMD5 - Automatically sets the Content-MD5 header on
all String bodies - metacpan.org
Plack::Middleware::ContentMD5 - Automatically sets the Content-MD5 header on
all String bodies...
Automatically sets the Content-MD5 header on all String bodies
View on metacpan.org Preview by Yahoo
I could be talked into adding that as well, although maybe not everyone wants
the overhead.
Any thoughts on that? --jnap
On Wednesday, April 23, 2014 6:50 PM, Trevor Leffler tleff...@uw.edu wrote:
I've been playing with a toy application and inspecting its responses to
various HTTP methods and noticed that Content-Length is missing from the
HEAD response. Both Catalyst::Action::RenderView and C::A::Serialize
(from the C::A::REST package) seem to take the easy way out and return
1 if $c-req-method eq 'HEAD'. Does anyone with CAR history know why
this is?
To provide message-body-based headers (content-length, last-modified,
content-md5, etc) I'm doing this:
sub render : ActionClass('RenderView') { }
sub end : Private {
my $self = shift;
my ($c) = @_;
$c-forward('render');
# see also Catalyst::Action::RenderView or ::Serialize
if ($c-req-method eq 'HEAD') {
my $view = $c-view
|| die sprintf(%s could not find a view to forward to.\n,
__PACKAGE__);
$c-forward($view);
}
#
fun with headers, for example...
# or enable P::M::ContentMD5
if ($c-res-has_body) {
my $md5 = Digest::MD5::md5_hex($c-res-body);
$c-res-headers-header(Content-MD5 = $md5);
}
}
I've noted that while $c-res-body now has my rendered view, it gets
removed by Plack::Middleware::Head prior to returning the response, so I
don't have to worry about that detail.
--Trevor
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
