On Sunday, December 22, 2013 12:33 AM, neil.lunn <n...@mylunn.id.au> wrote:
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
___
Niel,
I'm reviewing the plack issue you created. One thing though, in the future it
should not be so important for a catalyst application to run via *.psgi since
you can configure middleware and mount other applications directly. The only
cases where having a psgi file would be useful is when you want to tie together
applications with shared behaviors when the applications are not really part of
each other. So if we have this working correctly under runner, that's pretty
good I think! Base on that I think this issue could belong to plack and we can
hack on it over there. Which is ultimately my goal, which is to reduce the
amount of custom behavior in Catalyst so that we can share the development load.
John
>
>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 <mose...@hank.org> wrote:
>
>On Fri, Dec 20, 2013 at 8:34 PM, neil.lunn <n...@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@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/
________________________________
This email is free from viruses and malware because avast! Antivirus
protection is active.
_______________________________________________
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/
________________________________
This email is free from viruses and malware because avast! Antivirus
protection is active.
_______________________________________________
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/
