date:20131101

Re: [Catalyst] Re: Response traits.

2013-11-01 Thread Bill Moseley

On Fri, Nov 1, 2013 at 8:31 AM, John Napiorkowski  wrote:

> I think a patch that made sure strings being set to location conformed to
> the expected standard would be very welcomed!
>
> on the other hand I thought this was also caught by
>
> https://metacpan.org/pod/Plack::Middleware::Lint
>

Yes, you might be right about that.   That's probably the right (final)
place to catch this.   From the framework point of view I'm not quite clear
what $res->redirect should accept.   That is, if it contains \n should it
get precent-encoded?   Maybe it should (have) only accept a URI object?
And only a fully-qualified URI.And what if redirect is passed wide
characters?  Maybe it's legit to pass wide characters encoded in some
format.


>
>
> as well?  In any case Catalyst response could reject any attempts to set
> ->location with incorrect values.
>
> The only thing is that people could still probably get around it by
> setting headers directly.  I think for now we'll say if you do that we have
> to assume you know what you are doing!
>

One would hope.   Experience often shows that manually doing it often is an
indicator of not knowing what one is doing.   The framework's benefit is so
you don't screw things up.




>
> John
>
>
>   On Thursday, October 31, 2013 7:03 PM, Bill Moseley 
> wrote:
>
>
>
> On Thu, Oct 31, 2013 at 2:34 PM, John Napiorkowski wrote:
>
> I'm currently recommending people take advantage of native PSGI support in
> the newer Catalyst and use Middleware for when you need to munge and or
> alter the response (if its being done globally).  The interface is more
> straightforward.
>
>
> Do you think that Catalyst::Response should validate the location provided
> to redirect()?
>
> The issue that came up was a newline was ending up in the location
> provided which resulted in a split 
> response.
>I was thinking of doing something like:
>
> $self->location( URI->new( $location )->as_string );
>
> But with perhaps a bit more error handling.
>
>
>
>
>
>
>
> johnn
>
>
>On Thursday, October 31, 2013 11:33 AM, Bill Moseley 
> wrote:
>
> On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis wrote:
>
> CatalystX::RoleApplicator
>
>
> Thanks.  That was what I was looking for.   Just missed it when looking.
>
>
> --
> Bill Moseley
> mose...@hank.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/
>
>
>
> ___
> 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/
>
>
>
>
>
> --
> Bill Moseley
> mose...@hank.org
>
>
>


-- 
Bill Moseley
mose...@hank.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/

Re: [Catalyst] $c->write() buffering?

2013-11-01 Thread John Napiorkowski

I was reviewing code last night for release of Catalyst Hamburg dev5 and saw 
that $c->res->write is just calling the writer under the hood.  So as long as 
your headers are ready to finalize, that should be fine as well.  Just remember 
this approach is going to block, so be careful with anything  that is taking a 
lot of time.  --jnap



On Thursday, October 31, 2013 4:34 PM, John Napiorkowski  
wrote:
 
Recent releases of Catalyst makes it possible to stream write, although you 
need to be careful when using a blocking web server (long stream will of course 
block the available listener).

Older versions of Catalyst had similar ability with the write method, I never 
used it, and would be happen to get patches or test cases to make it work as 
we'd like.

Here's a link to an example, this one assume AnyEvent as a loop, but you could 
use a similar technique with any web server, as long as you don't mind blocking:

https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh


If you follow that, you will see stuff 'stream' as you wish unless there is 
some buffering going on at some other level of the stack.

Johnn



On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke  
wrote:
 
I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.


On Oct 31, 2013, at 10:12 AM, Daniel J. Luke  wrote:
> We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
> it's using Catalyst::Engine::FastCGI which just does *STDOUT->syswrite()
> 
> I guess I try to do some testing with newer Catalyst (and maybe alternate 
> deployment methods), to see if that changes anything. Looking through the 
> Changelog, I didn't see anything specifically related to this, though 
> (although I imagine the Plack stuff makes it somewhat different in the more 
> recent releases). 
> 
> On Oct 30, 2013, at 11:03 PM, Hailin Hu  wrote:
>> It is an engine relevant stuff.
>> Find which engine you are using ( for example, Plack::Handler::FCGI )
>> and look around codes around write(r), you may find something.
>> Good luck :)
>> 
>> On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke  wrote:
>>> I've got some legacy CGI code that does a bunch of processing and uses the 
>>> old hack of $| = 1; print "foo\n"; do_work(); print "foo done\n"; etc. 
>>> (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
>>> 
>>> While I'll eventually convert it to a job queue, I'd like to create an 
>>> output-identical implementation first with Catalyst, however it seems like 
>>> I'm getting output buffering when I don't want it.
>>> 
>>> As a very simple test, I've set up apache 2.2, mod_fastcgi 
>>> (FastCgiExternalServer with -flush and without -flush) and a method like 
>>> this:
>>> 
>>> sub test: Local {
>>>   my ($self, $c) = @_;
>>> 
>>>   $c->res->body('');
>>>   $c->response->content_type( 'text/plain; charset=utf-8' );
>>>   $c->finalize_headers;
>>> 
>>>   my $i;
>>>   for($i=1;$i<8;$i++) {
>>>       $c->write("$i: foo bar baz\n");
>>>       sleep(1);
>>>   }
>>> }
>>> 
>>> I see all the data at once in my browser instead of a line every second, 
>>> and with tcpdump, can see that all of the data is coming back in one packet 
>>> and not in 8+ smaller packets like I expect. If I make the string that gets 
>>> passed to write longer, I get several packets, but all at once (and not 
>>> with each iteration through the for loop).
>>> 
>>> Am I missing something obvious? Is there some way to get the behavior I'm 
>>> expecting?

--
Daniel J. Luke                                         
                         
++                      
  
| * dl...@geeklair.net * |                      
    
| *-- http://www.geeklair.net -* |                      
    
++                      
  
|   Opinions expressed are mine and do not
 necessarily   |                          
|          reflect the opinions of my employer.          |                      
    
++




___
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/___

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

2013-11-01 Thread John Napiorkowski

Catalyst::Test uses Plack::Test under the hood.  That mangle_response stuff is 
mostly evil :)

Sounds like you are saying you'd like to apply Plack Middleware during testing. 
 The latest dev release on CPAN lets you configure middleware via 
configuration, so you could have some middleware in your test configuration.  
This use case is one of the reasons I added this feature, so that we could 
manage middleware for catalyst inside of catalyst configuration.

If you don't like that approach, I could be talked into a patch to 
Catalyst::Test that would let you declare additional middleware in the test 
case.

I'd prefer this over messing with Catalyst::Test internals.  One of the hard 
things about trying to move Catalyst forward is that we've expose a ton of API 
that we fear to change since we don't know who is overriding what in the 
Darkpan.  Ideally I'd like to see people use Plack Middleware for jobs 
involving modifying the request and response, since that is something its great 
at, and the API is just a code ref, so its very well decoupled (could even be 
used outside of Catalyst).

Good luck!

John

On Thursday, October 31, 2013 8:26 PM, Toby Corkindale  wrote:

On 1 November 2013 12:01, Kieren Diment  wrote:
> You mean you want two apps interacting with each other in the same script 
> using WWW::MEchanize?  Eden and I were working some docs up on that topic 
> until real life intervened.
>
> This was the start of it:
>
> http://paste.scsys.co.uk/273844

Not exactly -- in this case I have a PSGI layer that is supposed to
inject some extra information into the env for consumption by the
application.

A simple example would be if you had a PSGI layer providing, say,
Basic HTTP auth, and setting the REMOTE_USER variable.
Although in my case, there's a bit more to it than that.

T

> On 01/11/2013, at 11:39 AM, Toby Corkindale wrote:
>
>> Umm, not that I know of.
>>
>> I suppose another way to phrase the question is: Is there a way to
>> manipulate the $c->engine->env in the Catalyst application, from
>> within unit tests neatly?
>>
>> On 1 November 2013 08:35, John Napiorkowski  wrote:
>>> Not sure what you mean, is there an example in another framework you can
>>> point to?
>>>
>>> johnn
>>>
>>>
>>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale 
>>> wrote:
>>> Hi,
>>> I wondered if there's any prior art around on inserting (mocked) PSGI
>>> layers into Test::WWW::Mechanize:Catalyst?
>>>
>>> Cheers,
>>> Toby
>>>
>>> --
>>> Turning and turning in the widening gyre
>>> The falcon cannot hear the falconer
>>> Things fall apart; the center cannot hold
>>> Mere anarchy is loosed upon the world
>>>
>>> ___
>>> 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/

>>>
>>
>>
>>
>> --
>> Turning and turning in the widening gyre
>> The falcon cannot hear the falconer
>> Things fall apart; the center cannot hold
>> Mere anarchy is loosed upon the world
>>
>> ___
>> 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/

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
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/

Re: [Catalyst] Re: Response traits.

2013-11-01 Thread John Napiorkowski

I think a patch that made sure strings being set to location conformed to the 
expected standard would be very welcomed!

on the other hand I thought this was also caught by 

https://metacpan.org/pod/Plack::Middleware::Lint

as well?  In any case Catalyst response could reject any attempts to set 
->location with incorrect values.

The only thing is that people could still probably get around it by setting 
headers directly.  I think for now we'll say if you do that we have to assume 
you know what you are doing!

John

On Thursday, October 31, 2013 7:03 PM, Bill Moseley  wrote:

On Thu, Oct 31, 2013 at 2:34 PM, John Napiorkowski  wrote:

I'm currently recommending people take advantage of native PSGI support in the 
newer Catalyst and use Middleware for when you need to munge and or alter the 
response (if its being done globally).  The interface is more straightforward.

Do you think that Catalyst::Response should validate the location provided to 
redirect()?

The issue that came up was a newline was ending up in the location provided 
which resulted in a split response.    I was thinking of doing something like:

$self->location( URI->new( $location )->as_string );

But with perhaps a bit more error handling.

>
>johnn
>
>
>
>On Thursday, October 31, 2013 11:33 AM, Bill Moseley  wrote:
> 
>
>
>On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis  wrote:
>
>CatalystX::RoleApplicator
>Thanks.  That was what I was looking for.   Just missed it when looking.
>
>
>
>-- 
>Bill Moseley
>mose...@hank.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/
>
>
>
>___
>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/
>
>
>

-- 
Bill Moseley
mose...@hank.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/

Re: [Catalyst] Re: Response traits.

Re: [Catalyst] $c->write() buffering?

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

Re: [Catalyst] Re: Response traits.

4 matches

Site Navigation

Mail list logo

Footer information