[Catalyst] Plack::Middleware::ContentLength problem
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 =
>> 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 :)
>> 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.
>> 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 =
>> 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.
>> 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: =
>> Dev site: http://dev.catalyst.perl.org/
>> List:Catalyst at lists.scsys.co.uk
>> Searchable archive:http://firstname.lastname@example.org=
>> 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://email@example.com=
> 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...
More information about the Catalyst