[Catalyst] Plack::Middleware::ContentLength problem

neil.lunn neil at mylunn.id.au
Sun Dec 22 06:32:05 GMT 2013

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.

> 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 =

>> <moseley at hank.org> wrote:
>> On Fri, Dec 20, 2013 at 8:34 PM, neil.lunn <neil at mylunn.id.au =

>> <mailto:neil at mylunn.id.au>> 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: Catalyst at lists.scsys.co.uk <mailto:Catalyst at 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 at 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.u=
>> 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: Catalyst at 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.u=
> Dev site: http://dev.catalyst.perl.org/

This email is free from viruses and malware because avast! Antivirus protec=
tion is active.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20131222/71be8=

More information about the Catalyst mailing list