Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/
Set by moderator on 25 January 2018.
02:57 ilbot3 joined
moderator Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/
10:04 sena_kun joined
Geth cro-http/push-promise: 176c7c2ef4 | Altai-man++ | t/http2-push-promise.t
Skip if no ALPN
 10:18
jnthn Ah, that'll fix the Travis :) 10:19
sena_kun Yeah. 10:20
a new adventure into FrameParser~ 10:21
jnthn Is all happy now with Chrome? 10:22
sena_kun first request - yes, a second one, where the headers are already indexed - no. 10:23
I suspect this bug can be... Anywhere, though, between hpack/frame parser.
10:33 Geth joined 10:51 Geth joined
sena_kun jnthn, I found it, but not sure how to fix it though. :/ 13:15
jnthn Was the HPACK patch you sent part of the fixing it? :) 13:27
Ah, and I'd still s/header-table/dynamic-table/ in the latest version of the patch 13:29
sena_kun not yet. 13:32
ugh.
jnthn, I clearly see issue's origin, but it's a concurrency one. If you have 3 minutes now, I can clearly explain it so you can suggest something. 13:33
jnthn OK, go on 13:35
sena_kun jnthn, firstly we get settings frame, that set some big table size, so we like `start $connection-state.settings.emit($result)` it(see github.com/croservices/cro-http/co...5b12154602 - this commit indeed fixes another issue). But then we got headers, that's just emitted(no start). Consumer firstly sees headers, then settings(eww), it uses the default table size, 13:38
cookies are thrown away, boom. Of course, if you remove `start`, it works, but other tests fail. I think we need to preserve all headers before we got first settings frame, but, well, the issue is more fundamentail, I think. start is naturally slower than plain emit.
*sets 13:39
jnthn Ah
And the start is there to make sure we don't get into deadlocks 13:40
sena_kun t/http2.t fails without it, like `# expected: '3'
# got: '0'`.
Failed test 'Concurrent responses are handled'
So we cannot remove it.
jnthn Maybe we can whenever start { $connection-state.settings.emit($result) } { put code that we want to do next here } 13:41
sena_kun in frame parser?
jnthn Yeah
So that we defer further processing until we know the settings emit happened 13:42
sena_kun it's quite async, I am not sure how it'll help. We need a lock, I guess.
Ah, stop, maybe start {}.get? 13:43
jnthn The start is there to avoid a deadlock as I remember it. I'm pretty sure that inserting more locking will not help.
We just need to enforce an ordering on the things we do, no? 13:44
sena_kun yeah.
jnthn So, moving the second emit of the headers into the body of a whenever, which will run after the settings change has been sent, should do it, I think?
sena_kun but I am not clearly see what we can put inside of whenever start now.
jnthn Ah, I see 13:46
Hmm... 13:47
sena_kun *seeing
jnthn Yeah, looking more at the code, I see
Also trying to remember why we needed that `start`
sena_kun the PR can be merged, I guess.
jnthn Which tests fail, precisely? 13:48
sena_kun http2.t
I'll push updated cro-http now...
Geth cro-http/push-promise: 0d727c18f1 | Altai-man++ | lib/Cro/HTTP2/GeneralParser.pm6
Use table size limit setting
 13:49
sena_kun You need this and patched HPACK, then `perl6 -I../../p6-http-hpack/lib/ -Ilib t/http2.t`.
Of course, relative path is so relative.
jnthn Merged PR, btw 13:50
Can you see what happens if we do $client ?? (start ...) !! (...) ?
That is, only async send it when we're in client mode?
sena_kun trying it. 13:51
jnthn (Currently looking at something else, so can't try it out right now) 13:52
sena_kun np
it works with both http2.t and in chromium. \\o/ 13:53
running other tests now...
jnthn++ 13:55
Geth cro-http/push-promise: fa6ab2c501 | Altai-man++ | lib/Cro/HTTP2/FrameParser.pm6
Fix race, jnthn++
 13:57
jnthn Nice :) 13:59
sena_kun ># Looks like you failed 3 tests of 4 14:00
kill me please. :]
jnthn arggh
sena_kun looking into it...
Geth cro-core: 33fb5d9437 | Altai-man++ | lib/Cro/Message.pm6
Lower binary blob limit to 512

4096 is quite a too much, since servers(e.g. akamai) generally sends data in smaller chunks, but even e.g. 2048 is tedious to see.		 14:31
sena_kun made limit lower.
>MoarVM panic: Heap corruption detected: pointer 0x7fa0f4398ac8 to past fromspace 15:06
I guess it's not exactly Cro issue here...
jnthn Uh, no 15:08
Geth cro-http/push-promise: 47d9a920f6 | Altai-man++ | 3 files
Allow for client to enable push
 15:09
cro-http: Altai-man++ created pull request #20:
Push promise support		 15:11
jnthn sena_kun: Ready for merge, in your opinion? 15:13
sena_kun not yet, I'm resolving conflict in META now. 15:14
:)
about "readiness", well... It passes all tests, works in both main browsers, with curl and some other tools.
jnthn You tried push promises and saw Chrome dev tools reporting that the thing was pushed, also? 15:15
sena_kun will try it now, yup.
Geth cro-http/push-promise: 5a7b913b09 | Altai-man++ | 8 files
Implement JWT-based Auth with tests;

Also reformat META6.json to use 4 white space characters.		 15:19
cro-http/push-promise: b233caae47 | Altai-man++ (committed using GitHub Web editor) | 8 files
Merge branch 'master' into push-promise
sena_kun Fixed the conflict, doing yet another test for push promises...
jnthn Just uploaded IO::Socket::Async::SSL 0.6 to CPAN 15:31
sena_kun *sighs* 15:43
jnthn, where we can get :authority? Is it a configurable value? 16:41
jnthn tools.ietf.org/html/rfc7540#section-8.1.2 16:42
8.1.2.3 specifically
sena_kun well, I see it right now. :) 16:43
jnthn "Clients that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host header field.
Are we doing that? :)
sena_kun I'm trying it with firefox now.
and chromium too.
jnthn Ah, you're looking at the mention of this in 8.2 on Push Promises? 16:44
The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative (see Section 10.1). A
client MUST treat a PUSH_PROMISE for which the server is not
authoritative as a stream error (Section 5.4.2) of type
sena_kun yes
jnthn PROTOCOL_ERROR.
sena_kun Yup.
Though, when I fixed that I'm still getting STREAM_REFUSED.
And like no reasons why so.
:/
RFC defines it as "When client for some mystical reason doesn't want to...". 16:45
so we need to pass :authority further to respond with it... 16:47
jnthn We could in the first instance pass in the :host of the server
To the response serializer
sena_kun yeah. 16:48
jnthn (When building up the pipeline, it's easy to pass it in to the constructor)
sena_kun do you want yet anothet flag?
*another
jnthn Flag? 16:49
Oh, in the API for Cro::HTTP::Server?
sena_kun yeah. you meant that, didn't you?
jnthn No, initially I thought just pass :authority($host) - that is, treat what's specified for $host
as a default
Though we could of course have a :$authority = $host 16:50
sena_kun well, I'm starting to melt at this point. :/
jnthn Time for a break? :) 16:51
sena_kun no. 16:52
www.youtube.com/watch?v=9VGKisqEAkE - never surrender, never retreat! 16:53
ok, good news: when ":authority" set to "localhost:$myport", the browser doesn't refuses. 16:55
so I guess our next thing is to figure out host:port.
aaaaah. 16:56
we already have host:port, so I just need to pass that.
jnthn Right :)
That said, we may want to let people pass :authority<foo.com> to Cro::HTTP::Server
And *default* it to what they pass for :host 16:57
sena_kun :authority must include port too.
jnthn Which in turn defaults to localhost
That should do it
sena_kun though for https it's just 443.
jnthn Ah, so just :$authority = "$host:$port" then :)
sena_kun yeah
also.
about all those options. 16:58
I didn't look there for a while(maybe a month or something), but it kind of looked like a mess with all those options. Not sure if it's just me. Perhaps, never mind me. Dunno if it can be organized better. 16:59
jnthn It'd be unusual for a given user-case to use the lot of them, though 17:01
sena_kun I mean the inner structure of Client. We just take a loooot of them and use it all around, so complexity of finding where is what and who passes what to who increases. 17:03
jnthn Oh, I thought we were talking about server :)
sena_kun Yeah.
I just changed the topic without noticing. 17:04
jnthn :P
sena_kun Everything was just in my head. :)
jnthn Perhaps we can do something smarter there
sena_kun Yeah. Not sure about time/efficienty ratio of such changes though. 17:05
jnthn Well, I figure we're talking internal changes, not external API ones, so we don't have to hurry too much 17:08
sena_kun sure.
jnthn yay, upload worked out nicely: modules.perl6.org/dist/IO::Socket::...cpan:JNTHN 17:12
Was a bit worried something mighta been off with it as I got dupe notification on #perl6 17:13
sena_kun chromium shows me 17:14
Initiator: Push (index) 17:15
So.
\\o/
Commiting changes...
tests first...
jnthn \\o/ 17:16
Geth cro-http/push-promise: 1f225ff2d2 | Altai-man++ | 2 files
Set :authority header
 17:19
sena_kun so.
I'll merge it, right?
jnthn Can do :) 17:20
Geth cro-http/master: 50 commits pushed by Altai-man++, (Jonathan Worthington)++
review: github.com/croservices/cro-http/co...cd30794be1
sena_kun phew. 17:21
moving to next task...
or is there something else you'd like to see implemented, jnthn?
jnthn I think that's all 17:22
I've got "Generalize body parsing" on my Cro todo list for this month
But I think we've already got plenty for a nice 0.7.3
sena_kun I can do it tomorrow/the day after tomorrow if there'd be some recommendations on generalization. 17:23
jnthn I think I'll take care of it, tbh; I'm not 100% sure what I want, and I think I need to play around with it a bit in code. 17:24
And there's not really much code to write 17:25
sena_kun ah, okay.
jnthn It's really just figuring out if we can extract some body-related logic to a more general role, so we can, for example, re-use things like JSON body parsing stuff on incoming websocket messages
Anyway, will see what I've time to do early next week on that 17:26
We've already got a lot of stuff done to make a nice release though 17:28
I think we'll manage 0.8.0 in February

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!