Camelia, the Perl 6 bug

IRC log for #mojo, 2013-06-02

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:16 sri love specs nobody thought through...
00:17 sri of course Link headers are impossible to parse with a proper header tokenizer
00:21 good_news_everyone joined #mojo
00:21 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/BD5Kow
00:21 good_news_everyone mojo/master 6dc3fcd Sebastian Riedel: more split_header tests
00:21 good_news_everyone left #mojo
01:12 bowtie left #mojo
01:53 russum joined #mojo
01:54 moltar joined #mojo
01:57 Meiermann joined #mojo
02:34 whitebook joined #mojo
03:02 asarch joined #mojo
03:03 good_news_everyone joined #mojo
03:03 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/EkIWeg
03:03 good_news_everyone mojo/master 2134999 Sebastian Riedel: added append method to Mojo::Headers
03:03 good_news_everyone left #mojo
03:04 fildon_ joined #mojo
03:10 marty joined #mojo
03:28 good_news_everyone joined #mojo
03:28 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/zBZPCw
03:28 good_news_everyone mojo/master 4c4837e Sebastian Riedel: better example for content negotiation
03:28 good_news_everyone left #mojo
03:29 travis-ci joined #mojo
03:29 travis-ci [travis-ci] kraih/mojo#742 (master - 4c4837e : Sebastian Riedel): The build was broken.
03:29 travis-ci [travis-ci] Change view : https://github.com/kraih/mojo/com​pare/21349996d643...4c4837e68ae1
03:29 travis-ci [travis-ci] Build details : http://travis-ci.org/kraih/mojo/builds/7701779
03:29 travis-ci left #mojo
03:33 good_news_everyone joined #mojo
03:33 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/zRWS1Q
03:33 good_news_everyone mojo/master 966d6e3 Sebastian Riedel: mention RFC of Link header
03:33 good_news_everyone left #mojo
03:35 travis-ci joined #mojo
03:35 travis-ci [travis-ci] kraih/mojo#743 (master - 966d6e3 : Sebastian Riedel): The build was fixed.
03:35 travis-ci [travis-ci] Change view : https://github.com/kraih/mojo/com​pare/4c4837e68ae1...966d6e318ef5
03:35 travis-ci [travis-ci] Build details : http://travis-ci.org/kraih/mojo/builds/7701812
03:35 travis-ci left #mojo
03:39 preflex_ joined #mojo
04:10 good_news_everyone joined #mojo
04:10 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/FBzyIQ
04:10 good_news_everyone mojo/master 12a1e59 Sebastian Riedel: added a little more HATEOAS to the routing guide
04:10 good_news_everyone left #mojo
04:29 good_news_everyone joined #mojo
04:29 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/NCBL1Q
04:29 good_news_everyone mojo/master e56c9c1 Sebastian Riedel: OPTIONS is also allowed
04:29 good_news_everyone left #mojo
04:32 russum On Mojolicious app 3.8x running under hypnotoad I was able to get list of files (I needed a list of all images) by doing:
04:32 russum opendir my($dh), "public/images/";
04:32 russum Now that I upgraded to 4.X - this doesn't work anymore.
04:32 russum Changing the path to "../public/images/" (since the app is started under scripts/ folder) doesn't work either.
04:32 russum When I change it to full path i.e. "/var/www/public/mojoapp/public/images" - everything works fine but I would prefer not to hardcode the full path.
04:32 russum How would the path look like to access files under the public/ directory?
04:33 russum Nothing significant was changed on the server, only the upgrade of Mojolicious to 4.x
04:43 russum "say $0" - shows /var/www/mojoapp/script/mojoapp
04:43 russum that's why I assumed the fix is simply "../public/images/"
04:43 russum but it just doesn't work, only the full hardcoded path works.
04:43 russum what other options should I try?
05:20 buu russum: I'm really not sure about 4.0 but isn't there a method/helper that gets you the current directory root directory?
05:20 buu Also your example was missing a few ..s
05:49 Britzel joined #mojo
06:29 basiliscos joined #mojo
07:10 cooper joined #mojo
07:30 d4rkie joined #mojo
07:30 Vandal joined #mojo
07:30 d4rkie joined #mojo
07:55 jzawodn joined #mojo
08:48 dotan joined #mojo
10:01 Vandal joined #mojo
10:12 suy joined #mojo
10:15 dotan joined #mojo
11:12 tba joined #mojo
11:14 tba hi all, quick question if anyones got a few minutes - is it possible to upgrade the socket in a Mojo::IOLoop::Stream using IO::Socket::SSL? initially seems to work but get errors from Mojo::Reactor::Poll and the stream errors and dies
11:16 tba these are the errors: http://mibpaste.com/TpHx83
11:23 bowtie joined #mojo
11:41 mire joined #mojo
12:01 whitebook joined #mojo
12:04 asarch joined #mojo
12:09 sh4 joined #mojo
12:18 al802 joined #mojo
12:20 al802 Can anyone advise on scaling Mojolicious, I seem to be hitting some bottleneck e.g.
12:20 al802 I cannot 8 cores gives 2k requests per second
12:21 al802 16 cores gives 2.5k or less requests per second
12:24 al802 Is there some synchronization of something going on in Mojo ?
12:25 al802 in the docs accept_interval states: Interval in seconds for trying to reacquire the accept mutex, what is this mutex
12:25 al802 also is there a different preforking/blocking mojo vs  preforking/non-blocking
12:28 suy al802: mojolicious is non blocking. Your code might block, though. Are you sure the bottleneck is in mojo, and not in the disk/database/whatever?
12:28 al802 my app does not block and servers everything from memory
12:28 al802 actually just a simple test page
12:31 al802 using 4 workers I get about 1.1k requests p/s (all to localhost)
12:32 al802 you would expect 8 workers to give 2.2k
12:33 al802 but only gives around 1.6k
12:33 al802 using 16 workers you would expect 4.4k
12:34 al802 but only gives 2k
12:35 al802 during my tests each worker uses 100% CPU
12:37 al802 with 32 works (I'm using 2xE5-2660 - 16 cores - with HT) I only get 2.3k
12:37 al802 so basically I cannot really scale beyond 4 theads
12:38 al802 I've tried (for may hours now tweaking the params http://mojolicio.us/perldoc/M​ojo/Server/Hypnotoad#SETTINGS with little or no change
12:39 inokenty joined #mojo
12:44 dod joined #mojo
12:44 libsysguy joined #mojo
12:59 moltar joined #mojo
13:25 mehltau joined #mojo
13:46 basiliscos joined #mojo
14:06 ynonp joined #mojo
14:09 basiliscos joined #mojo
14:26 * sri yawns
14:36 asarch joined #mojo
14:38 sri al802: there are way too many unknowns for anyone to be able to help you
14:39 sri for starters, you've not even established that you can generate more requests
14:40 sri or which mojolicious version and optional modules you've installed
14:40 denisboyun_ joined #mojo
14:41 sri or if your application does something stupid preventing proper scaling
14:43 sri if it really is hypnotoad (i doubt it), it shouldn't be too hard to track down and fix
14:43 sri stuff like the accept mutex can just be commented out
14:44 sri i don't have anything with more than 4 cores though, so can't try it myself
14:46 sri you've not even mentioned the concurrency level for crying out loud
15:00 ladnaV joined #mojo
15:04 Vandal joined #mojo
15:04 Vandal joined #mojo
15:21 good_news_everyone joined #mojo
15:21 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/bbUeZQ
15:21 good_news_everyone mojo/master 084419c Sebastian Riedel: added a few split_header examples
15:21 good_news_everyone left #mojo
15:21 sri split_header could still use a review
15:29 Adurah joined #mojo
15:31 moltar joined #mojo
15:33 al802 sri: Sorry for the lack of info, I think I need to put a test case together using a simple setup
15:34 al802 where is the accept mutex so I can comment it out ?
15:35 sri https://github.com/kraih/mojo/blob/ma​ster/lib/Mojo/Server/Prefork.pm#L177
15:36 sri you've also not said anything about the platform
15:38 al802 It's Linux 2.6.35.14 x86_64, 128G RAM,  2xE5-2660
15:38 al802 x4
15:38 sri such as how you've tuned network settings and limits
15:38 al802 these tests are all via localhost
15:40 al802 ab -n 10000 -c 100-2000 http://localhost/
15:40 sri lol
15:41 sri ok, your test setup is pretty flawed
15:42 sri localhost or actual network is irrelevant, you still need to tune your operating system
15:42 sri ab is garbage for benchmarks
15:43 sri without keep alive you'll run out of available descriptors in no time
15:43 al802 Well right now it's simple test
15:43 sri 10k is way way way low for proper tests
15:43 al802 but it does demonstrate my issue
15:44 al802 that was just an example, I do lots of tests, so 100k -c 10000
15:44 al802 which is the only way I can get the CPUs to stay @100% usage
15:44 al802 these procs are really fast
15:44 al802 I have no problem running 1000+ VMs
15:44 sri think i've given you enough pointers now
15:45 sri with that setup you'll never max out a server
15:45 al802 What do I need to return from mutex to fake it
15:45 sri just remove the whole mutex block
15:46 sri (set no callbacks at all)
15:46 al802 k
16:13 mrphilov joined #mojo
16:14 al802 so now at 4 workers, I get about 2k, this is about 100% faster, after losing the lock/unlock
16:20 al802 sri: what is the purpose of this lock, my app works fine without out it, so it would be nice to be able to disable it, maybe via ENV{'MOJO_NO_MUTEX'} or something link that
16:21 sri al802: those results are misleading, you should have been trying to saturate all your cores...
16:26 sri but since i don't want you to keep speculating... the problem here is that network services don't scale automatically, it's a skill you have to learn
16:26 sri you need to know what all those hypnotoad settings mean and how to tune linux, there's no way around it
16:27 sri i only mentioned that you can comment out the mutex because i didn't know how experienced you were, sorry about that, just don't do it
16:28 sri https://gist.github.com/kraih/5551292 # here's an example for a c10k test i did recently, i had to tune the components specifically for my use case
16:29 sri scaling properly is hard work
16:29 moritz .oO( scaling properly is O(hard) :-)
16:29 d4rkie joined #mojo
16:30 sri btw. an accept mutex addresses the so called thundering herd problem
16:30 sri :)
16:33 al802 It just seems that once the second CPU is used performance falls off the cliff
16:34 sri al802: does that change if you remove the mutex?
16:34 al802 removing the mutex seems to make a big difference but is only part of the solution
16:34 sri does it use all 16 cores?
16:34 buu joined #mojo
16:34 al802 if i use ab -n 40000 -c 8000 http://127.0.0.1/test
16:35 al802 all workers go 100%
16:35 sri that's irrelevant
16:35 al802 they also do it in a very uniform manner
16:36 sri you've just interpreted the thundering herd problem as a performance gain :)
16:37 sri (or rather a change in scalability)
16:37 al802 I've never heard of the herd problem :)
16:39 d4rkie joined #mojo
16:40 al802 I see (http://en.wikipedia.org/wik​i/Thundering_herd_problem)
16:41 al802 I don't think that is my problem here, my concurrency is 8000 and the average page response is .5ms so hopefully all the processes do wake up at once (in this instance)
16:41 sri that's another problem, your concurrency is not 8000, ab lies
16:42 al802 Damn, you just cant trust anything these days
16:42 * sri uses wrk exclusively
16:44 sri wrk has the ability to overwhelm most servers, with a little experience you can zero in on the real limit of your server, interpreting the number of timeouts and connection errors
16:45 Adurah Time to DoS sites I hate.
16:45 al802 netstat -n |grep EST|wc -l = 8221
16:45 al802 is wrk a cpan module ?
16:46 al802 ah, i see https://github.com/wg/wrk
16:59 d4rkie joined #mojo
16:59 al802 Results: http://mibpaste.com/Slo51y
17:00 al802 Interesting using 12 threads produces approx same results as using 32 threads?, the overall requests per second is 3k which is about the same as the ab testing
17:03 Adurah How many threads does your CPU support?
17:04 al802 32
17:04 Adurah Fun.
17:05 good_news_everyone joined #mojo
17:05 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/aGdtwQ
17:05 good_news_everyone mojo/master 3f33a80 Sebastian Riedel: do not recommend ab for benchmarking
17:05 good_news_everyone left #mojo
17:07 mrphilov1 joined #mojo
17:12 al802 running your test above, gives me same results using 2 threads ? http://mibpaste.com/H5xmNE
17:12 sri that commit wasn't for you, i'm out of the discussion
17:13 al802 just saying, using 2 threads hits same limit as 32
17:22 sri anyone got any thoughts about Mojo::Headers::append? should we encourage this or just multiple headers with the same name instead? https://github.com/kraih/mojo/commit/21​349996d643391d3e56828c397abbd683044cf6
17:23 sri here it's used in an example (Vary) https://github.com/kraih/mojo/commit/4c​4837e68ae11f8141132ee8497627973cd25f60
17:40 marty sri:  I'm not sure what the use case is for multiple headers but intuitively I grok appended headers more than multiple headers with the same name.
17:50 sh4 joined #mojo
18:08 asarch joined #mojo
18:11 sri marty: fun fact, they are equal ;)
18:12 sri Vary: Accept Vary: Accept-Encoding is equal to Vary: Accept, Accept-Encoding
18:12 mrphilov joined #mojo
18:13 sri multiple headers just take a little more space and some clients/servers have them implemented wrong
18:13 sri aside from aesthetics
18:13 * sri thinks single header is more pretty
18:15 sri there are also certain exceptions, like Set-Cookie, where the value can contain broken Expires token... so the cookie spec recommends the use of multiple headers instead of comma separated
18:28 rem_lex| joined #mojo
18:47 marty sri: that makes sense now, thanks.   I guess if there is a real-world possibility that you can have a broken token then the prudent approach would be the spec recommendation.
19:03 mrphilov joined #mojo
19:34 mrphilov joined #mojo
19:48 ajmrch joined #mojo
19:51 good_news_everyone joined #mojo
19:51 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/vPSbQQ
19:51 good_news_everyone mojo/master 0da1768 Sebastian Riedel: better examples for add and append in Mojo::Headers
19:51 good_news_everyone left #mojo
19:51 sri that should make the difference more clear
19:56 good_news_everyone joined #mojo
19:56 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/GLzOgg
19:56 good_news_everyone mojo/master ee41b6b Sebastian Riedel: fixed examples in Mojo::Headers
19:56 good_news_everyone left #mojo
20:18 * sri wonders if Mojo::Headers::split would be conveninent
20:23 mrphilov joined #mojo
20:31 good_news_everyone joined #mojo
20:31 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/lTeJqw
20:31 good_news_everyone mojo/master 3ced850 Sebastian Riedel: fixed a few small filename detection bugs in Mojo::Message
20:31 good_news_everyone left #mojo
20:42 jberger o/
20:43 jberger sri: so you still want a look in at some headers code and if so which?
20:43 jberger s/so/do/
20:43 sri split_header first
20:44 * jberger looks
20:44 sri append second
20:45 sri behavior should be mostly equal to HTTP::Headers::Util::split_header_words, but about twice as fast
20:45 sri i might have missed some special cases, but it passes all tests
20:48 mrphilov joined #mojo
20:49 * jberger is working to grok it a bit
20:52 jberger what is the reason for capturing the quotations and then running the capture result through unquote?
20:53 sri unescaping
20:53 sri "foo\"bar" is valid
20:53 jberger oh ok
20:54 sri and in turn "foo\\bar" too of course
20:54 jberger yeah, I should have seen that
20:56 jberger thats clever with the last few lines of the while loop
20:58 jberger ok, well it looks fine by me, as you say the tests pass too, I think its nice
20:58 sri we had it implemented in Mojo::Cookie anyway, figured making it reusable will come in handy
20:59 sri original commit https://github.com/kraih/mojo/commit/18​0cf67c93cc593c4f2f7873b2c2afa6cbfd1bb6
20:59 sri it changed a bit since then
21:00 sri i'm mostly worried about special cases i might be missing
21:01 sri like "foo=;bar=baz" and "foo,,,bar"
21:01 sri originally i was also treating "foo=bar baz" as "foo="bar baz""
21:02 sri while it should be "foo=bar; baz"
21:04 jberger I can't say I've been initiated into the special cases in headers, I
21:04 jberger oops
21:04 jberger I've always relied on a parser for them
21:04 jberger I've never parsed them manually enough to notice
21:04 sri many are supposed to follow a certain structure
21:05 sri with cookies and link headers it gets a bit ridiculous though :S
21:06 jberger I seem to remember Content-Disposition being weird
21:06 jberger generally I mean
21:06 sri Link: <http://example.com/foo?page=123>; rel="next"
21:06 sri how the hell do you tokenize that?
21:07 sri there's a "=" in the URL!!
21:07 jberger doesn't ; end the header too?
21:07 sri just the token
21:07 sri , ends the header
21:07 jberger oh I see
21:08 sri Link: <http://example.com/foo?page=123>; rel="next", <http://example.com/bar?page=1>; rel="first"
21:08 sri FUN!
21:08 jberger might need to go to a /gc style tokenizer rather than an s/// one?
21:09 sri what for?
21:09 jberger I think of that being more powerful
21:09 jberger if you were worried about it
21:10 sri i don't need more power, i need a logical solution
21:10 * jberger pulls out HOP
21:10 sri you'd need an entirely different strategy
21:11 sri like split up the headers on , and then parse the URL manually from each one, and only then tokenize the rest properly
21:11 jberger does the link always get <> brackets
21:11 jberger ?
21:12 sri yes
21:12 jberger shouldn't that make the "=" in the URL easy to handle?
21:12 sri no
21:13 jberger because that's not the case for other header?
21:13 jberger just Link?
21:13 jberger ok, I think I see your problem
21:13 sri Link: <http://example.com/foo?page=123&amp;test=1>; rel="n,e=x,t", <http://example.com/bar?page=1>; rel="f,i=r=s,t"
21:13 sri better example
21:13 sri that's a 100% valid Link header
21:15 sri we need [{url => 'http...', rel => '...'},...]
21:15 sri there is no way to do this with a generic tokenizer like split_header
21:16 jberger right, it seems to need a per-header-type tokenizer :/
21:17 sri it's funny that Set-Cookie in all of its ridiculousness is so much easier to fix https://github.com/kraih/mojo/blob/ma​ster/lib/Mojo/Cookie/Response.pm#L31
21:17 sri (Expires...)
21:20 btyler joined #mojo
21:21 sri good we are talking about it, found another bug :)
21:21 good_news_everyone joined #mojo
21:21 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/yMGT3Q
21:21 good_news_everyone mojo/master d7445d7 Sebastian Riedel: fixed cookie quoting bugs in Mojo::Cookie::Response
21:21 good_news_everyone left #mojo
21:21 jberger that might be all I'm go for here
21:21 jberger :-)
21:21 jberger this certainly isn't something I have thought much about before
21:22 sri LEARN ALL THE SPECS!
21:22 * jberger gives up programming, becomes a cheese maker
21:23 jberger I'm assuming headers are something that werem
21:23 jberger 't designed
21:23 jberger but grew up organically
21:24 * jberger is sorry, he seems to be missing the ' for the <enter> key today
21:25 jberger meanwhile, I have been tinkering with UV
21:25 jberger just to see
21:25 sri mmmmmm cheeese...
21:25 jberger mmmmmmmmmm
21:26 jberger I can't seem to figure an easy way to do Mojo::Reactor::UV::is_running
21:27 jberger I don't see anything like UV::depth
21:27 jberger vs EV::depth
21:29 sri that might be tricky if it doesn't have some kind of recursion counter
21:29 jberger I was trying to mock one using something like `local $self->{running} = $self->{running} + 1`
21:30 jberger but that seems like it probably has some faulty understanding
21:30 jberger (that would be in say ->start)
21:30 sri yea, that's problematic
21:30 sri then you couldn't have another event loop actually control UV
21:30 sri like AnyEvent
21:30 jberger plus its 'run_once' seems not to work how I expect
21:31 sri on the plus side UV::timer_again() looks convenient :)
21:32 jberger yeah
21:32 sri it could also be that an is_running function is available in libuv but not implemented yet in UV
21:33 jberger I looked at that, but I couldn't find it in libuv.h
21:33 ajmrch joined #mojo
21:33 jberger I've been referring to that more than the UV implementation
21:33 jberger there are certainly documentation problems in the UV doc
21:33 jberger for example UV::run_once doesn't exist
21:33 sri hmm
21:33 jberger best I can tell it should be UV::run(UV::RUN_ONCE)
21:34 sri ah right, same as libev then
21:34 jberger but thats not how its documented
21:34 jberger I had to look at the xs to see how its written
21:34 jberger :s
21:35 sri best reference is prolly comments in the node.js source -.-
21:36 lukep joined #mojo
21:38 sri in the libuv source i have found loop->stop_flag, maybe that's exposed somewhere
21:38 sri https://github.com/joyent/libuv/​blob/master/src/unix/core.c#L304
21:39 jberger oh, like that's some kind of recursion count?
21:39 * jberger digs
21:39 sri doubt it, but maybe it can tell you at least if the loop is running
21:40 jberger its just a struct member
21:40 jberger I don't know if UV exposes it, but it wouldn't be hard to add
21:41 jberger https://github.com/joyent/libuv​/blob/master/include/uv.h#L1992
21:42 jberger I almost wonder
21:42 jberger the header is so easy to read and the library so easy to build, I almost wonder if Mojo::Reactor::UV shouldn't just have its own xs bindings to libuv.so
21:43 jberger it would have to be its own distribution in that case though
21:43 jberger so maybe no
21:44 jberger but it seems that UV isn't complete enough
21:44 sri perl6 with libuv will be interesting
21:44 sri MoarVM sounds pretty pragmatic
21:44 * sri likes
21:46 sri jberger: depends if you really want to maintain a libuv binding long term
21:46 jberger probably not
21:46 tba anyone know how I can upgrade a IOLoop server to tls after the connection is accepted? using IO::Socket::SSL gets stuck on 'Net::SSLeay::accept -> -1' and eventually disconnects with 'SSL wants a read first'
21:46 sri if you want to i'd not make it mojo specific though
21:47 jberger sri: in that case, better just to work to improve the current UV project
21:47 sri tba: all i know is that it's not a supported feature
21:48 jberger the problem for me was that I was just tinkering to see how feasible it all is
21:48 * sri has not even considered is_running to be a problem :S
21:48 tba sri: np, was hoping to use IOLoop for non-HTTP connections (e.g. SMTP) but got stuck on the starttls command, thank you anyway
21:48 sri jberger++
21:49 sri tba: ah yea, starttls just doesn't make sense for our use cases atm
21:49 tba sri: didn't expect they would, but I loved the simplicity of reactor and IOLoop so had to give it a go :)
21:49 jberger <3 IOLoop
21:49 jberger in truth thats part of why I was tinkering with UV
21:49 jberger IOLoop is great
21:51 tba just wondering, for IOLoop, is setting up reactor->io and passing the handle to reactor->watch enough to get read/write happening? or am I missing something obvious?
21:52 tba seems to work beautifully using an IOLoop server with tls enabled from the start, which makes me think I'm missing something
21:52 sri tba: which mojo version?
21:52 tba sri: 4.07
21:53 sri upgrade to 4.10
21:53 sri just a hunch, but i've shuffled around some internals and fixed some server state code
21:53 tba sri: will give it ago, thanks
21:55 mrphilov joined #mojo
21:55 sri theoretically though... if you accept a connection $stream->steal_handle and ->remove() the stream, upgrade to tls manually, and ->stream(Mojo::IOLoop::Stream->new($tls_handle)) it should work
21:56 tba sri: just tried 4.10, same result as 4.07
21:57 tba sri: will give that a try now, at the moment it hangs on SSLeay accept and eventually I get a few errors from Mojo::Reactor::Poll
21:57 tba http://mibpaste.com/Zil9Ao
21:57 * sri has only done the tls upgrade on the client side so far
21:58 tba it bothers me that it works for the server when its started in TLS mode (so your code clearly works), but if I try and do the same thing after the initial accept it doesn't
22:01 sri tba: ah, you've duplicated the tls code from Mojo::IOLoop::Server?
22:02 tba sri: pretty much, a few minor changes but its mostly the same
22:02 * sri nods
22:02 sri it's rather minimal
22:04 sri <3 IO::Socket::SSL btw. it has improved so much
22:04 tba never needed to use it directly before, but its proving challenging :)
22:05 sri you should have seen it 3 years ago :p
22:06 tba I think there might be some other problem... I've used steal_handle, upgrading manually, and set the socket to blocking mode, and it still hangs at the same point - could it be my SSL configuration?
22:06 asarch joined #mojo
22:07 sri sure
22:10 mrphilov joined #mojo
22:15 sri tba: here's a fun patch http://pastie.org/7998267
22:16 tba sri: thank you! will try it now
22:17 sri it's just a quick hack to try if the STARTTLS code could be made reusable
22:19 tba looks good, similar to what I was trying to do I think, but in a lot less lines of code :)
22:19 sri theoretically we could allow manual upgrades... and just emit a different event for those
22:20 sri like "accept" for connections from the listen socket, and "upgrade" for manually upgraded handles
22:20 sri whole thing is not particularly elegant though
22:20 tba seems to work, or at least looks hopeful! after calling server->start_tls, I get garbage in my console :)
22:25 sri i suppose a cleaner solution would be a tls_manually option passed to the server that disabled automatic upgrade... which you can later start with ->start_tls
22:25 sri (should we ever decide to do this in core)
22:26 tba its definitely got a step further with your patch, my smtp client now thinks TLS negotiation completed and reissues EHLO
22:26 sri :)
22:27 tba it appears to still be encrypted when it reaches stream->on(read), the EHLO from the client is output as 'garbage' in my console
22:28 sri then you didn't actually upgrade the handle
22:28 sri you started the handshake but reused the old handle object
22:29 sri when you should have used the one wrapped in an IO::Socket::SSL object
22:29 kmx joined #mojo
22:31 tba at the moment I setup stream on error/close/read when I do my accept, so I just need to grab the new handle from IOLoop server and reattach the events?
22:31 sri destroy the whole old stream
22:31 sri make anew one
22:32 sri with a stolen handle the stream is busted
22:41 good_news_everyone joined #mojo
22:41 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/vhBgTA
22:41 good_news_everyone mojo/master bb1c32f Sebastian Riedel: more diverse redirect_to tests
22:41 good_news_everyone left #mojo
22:48 tba sri: no luck with your patch, I can get it back to where I was earlier stuck on SSLeay accept, I might still be doing something wrong though
22:49 tba the closest I can get is to set the handle to blocking mode, manually upgrade the connection and reattach, just a few more bugs to iron out
22:50 tba also your patch used $self->{tls}, which isn't set unless you start the server with TLS, and once you set it means all new connections have TLS - had to change start_tls to accept additional parameters
22:54 sri like i said, it was just a hack
22:57 asarch joined #mojo
23:07 good_news_everyone joined #mojo
23:07 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/aiqNpg
23:07 good_news_everyone mojo/master ab42300 Sebastian Riedel: fixed another cookie quoting bug
23:07 good_news_everyone left #mojo
23:12 mrphilov joined #mojo
23:16 sri jberger: oh, you didn't say anything about Mojo::Headers::append
23:26 good_news_everyone joined #mojo
23:26 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/-CG3NQ
23:26 good_news_everyone mojo/master 1c94e5f Sebastian Riedel: fix expires value a little more efficiently
23:26 good_news_everyone left #mojo
23:33 mrphilov joined #mojo
23:43 jberger doesn't seem like there's all that much to it really
23:43 jberger I didn't realize that Mojo::Headers just keeps strings
23:43 jberger I kinda assumed it had some kind of deeper data structure
23:44 sri it does
23:44 sri otherwise append wouldn't have to flatten it
23:45 * jberger looks again
23:46 jberger OH
23:48 sri Vary is a good example use case, since you negotiate stuff on different layers and add more values to it
23:49 sri example http://mojolicio.us/perldoc/Mojolicious/Guid​es/Rendering#Post-processing_dynamic_content
23:51 good_news_everyone joined #mojo
23:51 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/c2NkCg
23:51 good_news_everyone mojo/master d922b12 Sebastian Riedel: tweaked content negotiation example a little
23:51 good_news_everyone left #mojo
23:51 sri actually that's better :)
23:52 sri jberger: rubber duck debugging at work... i explain stuff to you and find bugs :) http://en.wikipedia.org/wiki/Rubber_duck_debugging
23:53 jberger I'm perfectly ok with that :-)
23:53 * jberger feels about as usful as a hunk of plastic lately actually

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary