[Catalyst] Plack::Middleware::ContentLength problem

Sun Dec 22 14:32:13 GMT 2013

On Sunday, December 22, 2013 12:33 AM, neil.lunn <neil at 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 <moseley at hank.org> wrote:
> 
>On Fri, Dec 20, 2013 at 8:34 PM, neil.lunn <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
>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.uk/ Dev site: http://dev.catalyst.perl.org/ 

________________________________

   This email is free from viruses and malware because avast! Antivirus 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.uk/ Dev site: http://dev.catalyst.perl.org/ 

________________________________

   This email is free from viruses and malware because avast! Antivirus 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.uk/
Dev site: http://dev.catalyst.perl.org/