On 22/12/2013 3:26 PM, neil.lunn wrote:
Not jumping around on this any longer. Changing
Plack::Util::content_length seems to be the most sane answer.
'is_real_fh' does good for guarding against things that are not going to
return a valid file descriptor, as would be requried by IO::AIO functions.
Hopefully the proposed change gets some traction and is accepted.
https://github.com/plack/Plack/issues/439
On 22/12/2013 7:47 AM, John Napiorkowski wrote:
The current HEAD of the runner branch actually has beta code that
replaces the existing logic for calculating content length when its
not set with this Plack middleware (we also replace some custom
logic to remove the content body when the request is HEAD with
similar Plack middleware). So this work is useful to help us shake
out and improve the common middleware bits.
Was hoping that would be the case. Checked out the current HEAD of
runner to confirm tests
Over the coming time I plan to move more and more custom code into
middleware when it makes sense. The goal is to reduce the amount of
custom code in Catalyst and move some of the burden of maintenance
onto the broader Plack community.
And hopefully other frameworks do the same so the Plack parts remain
common.
However I am unclear what the failing cases is this example are...
Is is possible to contrive a failing case for the content length
middleware we can bring to #plack / miyagawa?
Still working on something that solves but with some work I got a
reproducible result on plain PSGI and also on the runner branch. The
good news being I can get the ContentLength middleware to correctly
report on the handle even under 'runner'.
The not so good news is that first suspicions were right. As I had in
a base test script, it is the order of Plack::Util loading that is the
problem. To make the 'is_real_fh' function work in this case, I am
overriding perl's built in 'fileno'. Problem being that the
Plack::Util is being pulled in before the code that overrides the
built in is being loaded. Thus the 'fileno' call within 'is_real_fh'
is still pointing to CORE.
The reason is Plack::Runner as Plack::Util is in it's imports before
parsing the content of a supplied *.psgi file in the arguments. If
instead this is manually scripted (ie plain script invoking
Plack::Runner) and the symbol table alteration is loaded first, well
then all is okay.
Most deployments will probably use the *.psgi file to setup. So trying
to find a way around this or otherwise have a different way to change
symbol table. But mostly looking like chicken and egg stuff :)
Neil
I recommend anyone interested to start pulling from the HEAD of the
runner branch if they want to play with it. I want to ponder the
best approach to using middleware for core app functionality
(pondering how Rails middleware stack works, and looking at
PlackX::MiddlewareStack for examples.) Right now in HEAD the core
middleware is just tacked onto the top of registered_middleware.
Thoughts on the best way to architect this are very welcome. I see
in the nearish future a good chuck of stuff that is in Catalyst.pm
and related files moving into Middleware, possibly including the
debugging screens, errors screens, etc. In Rails and Django for
example all that stuff is in middleware to make it easier for people
to pull out and hack on it.
John
On Saturday, December 21, 2013 9:38 AM, Bill Moseley
<[email protected]> wrote:
On Fri, Dec 20, 2013 at 8:34 PM, neil.lunn <[email protected]
<mailto:[email protected]>> wrote:
....
My article today actually
(http://www.catalystframework.org/calendar/2013/21), even though
I'm actually talking here about the above case.
Just a note on the Advent article.
Thanks for writing that up. It's a well-written article and clearly
explains the issue I was facing and the fix you provided to me. One
thing I really like about the Advent articles is that I learn new
ways to do things. For example, I wasn't aware of namespace::sweep
and never thought about overriding the -X filetests. I just set the
content length manually now in the Controller along with the body.
I'm was also very happy to see you building this into a model at the
end. I sometimes wonder if that is not stressed enough when learning
Catalyst. I see a lot of code written into controllers at work that
should really be models. I will pass the link to the Advent article
around.
In my specific situation for this problem I already had a model.
The gzipped files are stored on a distributed file system and I
already had a model class for fetching files. I just extended that
to handle these gzipped files. But, I think your solution is a bit
more elegant and, well, more correct because it can be used more widely.
Thanks,
_______________________________________________
List: [email protected] <mailto:[email protected]>
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
_______________________________________________
List:[email protected]
Listinfo:http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:http://www.mail-archive.com/[email protected]/
Dev site:http://dev.catalyst.perl.org/
------------------------------------------------------------------------
<http://www.avast.com/>
This email is free from viruses and malware because avast! Antivirus
<http://www.avast.com/> protection is active.
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
