The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2014-10-22

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

All times shown according to UTC.

Time Nick Message
00:06 Lee_ joined #mojo
00:29 neilhwatson joined #mojo
00:30 neilhwatson Hi, I have this strange problem where the app, via morbo or HT return css files as text/plain instead of text/css. What might the cause be?
00:49 marty neilhwatson: do you files end in .css
00:49 marty s/you/your/
00:50 neilhwatson Yes
00:50 jberger franzkafka: I wonder what tempire thinks of that
00:51 * tempire prefers manjar
00:52 neilhwatson Browser console log reports: http:/....css/custom.css was not loaded because its MIME type, 'text/plain', is not 'text/css'.
00:53 bpmedley neilhwatson: Can you make a Mojolicious::Lite example that does the same thing?
00:53 neilhwatson I can show you the full mojo app, it's very small.
00:54 marty Just a guess, but maybe you have a hook that is setting $self->res->headers->content_type('text/plain') for all requests
00:55 neilhwatson No, not header manipulation.
00:56 neilhwatson This is it: https://gist.github.com/neilhwatson/c2220629eeb9510b355b
00:57 zivester joined #mojo
01:07 marty Another shot in the dark.   make sure your template has the correct tag.  ie: <link rel="stylesheet" type="text/css" href="somefile.css">
01:07 disputin joined #mojo
01:07 marty That is assuming you are serving your css files from public
01:11 neilhwatson Yes, and yes. Even if I call the css directly from the browser it still  gets the plain text header.
01:15 Mso150 joined #mojo
01:17 * marty is out of ideas
01:20 fhelmber_ joined #mojo
01:30 klapperl joined #mojo
01:35 neilhwatson Fixed I think. My guess is I was using some hybrid of system perl and perlbrew.
01:42 neyasov_ joined #mojo
01:56 preaction joined #mojo
02:47 noganex_ joined #mojo
03:41 basic6_ joined #mojo
03:51 KCL joined #mojo
04:17 rem_lex|pivo joined #mojo
04:39 preaction joined #mojo
05:03 ashimema joined #mojo
05:21 fhelmber_ joined #mojo
05:22 d4rkie joined #mojo
05:27 sujithm joined #mojo
06:02 sujithm joined #mojo
06:07 sujithm_ joined #mojo
06:15 sujithm joined #mojo
06:25 Kovensky joined #mojo
06:39 sujithm_ joined #mojo
06:47 Mso150 joined #mojo
06:53 Mso150 joined #mojo
07:06 sujithm joined #mojo
07:08 rawler joined #mojo
07:13 dp_ joined #mojo
07:17 basiliscos joined #mojo
07:19 trone joined #mojo
07:20 sujithm_ joined #mojo
07:22 Vandal joined #mojo
07:23 vytas joined #mojo
07:45 arthas joined #mojo
07:46 irq joined #mojo
07:49 sujithm joined #mojo
07:51 fhelmber_ joined #mojo
08:08 sujithm joined #mojo
08:15 camelo joined #mojo
08:16 neyasov_ joined #mojo
08:21 camelo Hi
08:28 tempire Hi
08:29 aleksey joined #mojo
08:37 meshl joined #mojo
08:40 Dandre hello,
08:41 irq_ joined #mojo
08:42 Dandre I have a question about stash values: can a get or post request set a stash value or are stash values privates to the application?
08:43 camelo they're private
08:44 meshl joined #mojo
08:44 Dandre ok thanks
08:44 camelo and they should be, user input should be validated...
08:45 hlin joined #mojo
08:47 sujithm_ joined #mojo
08:48 D4RK-PH0ENiX joined #mojo
09:11 dod joined #mojo
09:18 marcus_ joined #mojo
10:12 nicomen1 joined #mojo
10:28 denis_boyun joined #mojo
10:47 markov joined #mojo
11:00 denis_boyun_ joined #mojo
11:01 arpadszasz joined #mojo
11:25 arpadszasz joined #mojo
11:31 basiliscos joined #mojo
11:34 asarch joined #mojo
11:51 sujithm joined #mojo
11:53 sujithm_ joined #mojo
11:57 d4rkie joined #mojo
11:58 sujithm joined #mojo
12:13 basiliscos joined #mojo
12:15 d4rkie joined #mojo
12:18 neilhwatson joined #mojo
12:42 Kripton joined #mojo
12:51 odc WHY ARE YOU NOT CELEBRATING CAPS LOCK DAY?
12:56 hernan whats the correct usage of session expire time in startup ?
12:58 hernan neverming
13:01 ver joined #mojo
13:09 tbushell joined #mojo
13:09 lipizzan joined #mojo
13:11 tbushell left #mojo
13:14 basiliscos Hello! I have the following little application: http://pastebin.com/XZe4i3ZV. Please, note the my $filename = 'проблема.jpg'; - it is in russian.
13:14 basiliscos When the code is actually executed I got infinite list of error: Mojo::Reactor::EV: Write failed: Wide character in syswrite at /home/basiliscos/perl5/perlbrew/perls/perl-5.20.0/lib/5.20.0/x86_64-linux/IO/Handle.pm line 483.
13:16 basiliscos Could anybody reproduce it?
13:16 basiliscos curl  -Fartwork=@/tmp/empty-file  http://127.0.0.1:3000/api/file/artwork
13:16 basiliscos What to do?
13:16 Nei you probably need to add an utf8::encode($filename)
13:16 nicomen and hope that the underlying file system accepts it
13:17 nicomen another thing could be to url encode the filename
13:17 basiliscos yes, underlying fs accepts it
13:17 nicomen oh sorry I thought you were accepting files, not uploading
13:17 espent joined #mojo
13:17 nicomen what Nei said then ;)
13:18 Nei --turn your utf8 string into bytes first when it leaves perl
13:19 basiliscos Success!!!
13:19 basiliscos Thank you!
13:20 Nei the rule of encodings, "decode" when some bytes come into your app, "encode" when it leaves the app
13:20 basiliscos I have to do reverse operation with json:
13:20 basiliscos '<%== decode('utf8', j($default_settings) ) %>' - in the bootstrap template
13:21 basiliscos but when I answer directly to user ($c->render(json => ...) - it handles utf8 internally
13:21 Nei sadly there does seem to be some inconsistencies
13:21 Nei like "text" will do some encoding, "data" wont, etc
13:22 Nei but these inconsistencies are on Mojo level afaik, not perl
13:22 basiliscos Wonderful community rounds angles rather well :)
13:25 Nei to_json returns bytes so you have to decode it, it's like bytes coming in to your app. you are embedding that in a template that is going to be interpreted, and automatically encoded, that's why you need to decode it
13:26 basiliscos Nei: thanks for explanation
13:31 tadamo joined #mojo
13:32 tadamo left #mojo
13:44 jberger_ joined #mojo
13:45 ignacio_ joined #mojo
13:45 jberger_ Nei: how is that inconsistent?
13:46 jberger_ http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Rendering-data
13:47 jberger_ That is the documented behavior
13:47 Nei just because everything is properly documented doesn't mean it is immediately on the minds of people
13:48 jberger_ Use text if you want to encode, user data if not
13:48 jberger_ Nei: that doesn't imply inconsistency
13:48 Nei for example what about templates
13:49 jberger_ That is text, so it gets encoded
13:49 jberger_ Data lets you handle your own encoding, or send raw bytes like if you generate some image on the fly
13:49 jberger_ Why would you want that data encoded?
13:49 Nei where is that documented?
13:50 jberger_ Everywhere
13:50 jberger_ Mojo is incredibly careful about encoding
13:51 Nei probably, but I didn't find it in "Rendering"
13:51 jberger_ Just personally I have spent hours with sri discussing encoding
13:51 Nei of course the unicode heart might give a clue
13:51 Nei also ByteStream is named confusingly
13:52 jberger_ Nei sorry, but in the end, if the doc says it then it is what it is
13:53 Nei sure. note how I never said "the docs are wrong" or "mojo is wrong"
13:53 jberger_ if you can't be bothered to read the doc then I can't help you
13:53 jberger_ Actually you kinda did and I took offense
13:53 Nei you feel personally offended. don't worry, I still like mojo
13:54 jberger_ http://irclog.perlgeek.de/mojo/2014-10-22#i_9548030
13:55 jberger_ Think what you want, but when you say it out loud and to another user, I have to come to the defense
13:56 Nei what would be your favourite receipe of embedding json?
13:56 jberger_ What do you mean embedding?
13:57 Nei the issue basiliscos was talking about
13:57 Nei http://irclog.perlgeek.de/mojo/2014-10-22#i_9548021
13:57 jberger_ That is a discussion we have been having for weeks
13:58 jberger_ That is not embedding json, that is embedding a JavaScript object literal
13:58 jberger_ A subtle but important difference
13:58 Nei excuse me for not following every of your discussions, was a conclusion reached :)?
13:59 jberger_ I actually have been arguing for a feature like that, but we have not come up with a resolution yet
13:59 Nei it could also be written as b(j())->decode
13:59 jberger_ In the meantime the recipe he showed is the best way atm
14:00 jberger_ I believe that would also work
14:02 jberger_ joined #mojo
14:18 sri Nei: i found that offensive too
14:20 sri there is no inconsistency, perl requires us to differentiate strongly between methods and functions that handle bytes and characters
14:20 sri jberger_: there is Mojo::JSON::to_json
14:21 Trelane so, I just spent some time working on this issue
14:21 Trelane basically the best solution I have come up with is rendering the JSON you're embedding into JavaScript into ascii
14:22 Trelane this nicely sidesteps the issue that json, by defintion, should be utf-8
14:23 Trelane where embedded json-like stuff you put into JavaScript should obviously be characters until it's finally rendered out
14:23 sri http://mojolicio.us/perldoc/Mojo/JSON#to_json
14:23 sri it's easier than that
14:24 Trelane yeah, having another function documentated like that is pretty awesome
14:24 sri the real problem is actually http://timelessrepo.com/json-isnt-a-javascript-subset
14:24 sri which Mojo::JSON handles automatically, to to_json generates a real JavaScript subset
14:25 sri s/to/so/
14:25 Jonneh_ joined #mojo
14:27 sh4 joined #mojo
14:28 sri Nei: since you've been telling others that mojolicious is inconsistent, i do now expect an issue on github where you explain all inconsistencies so we can fix them
14:28 sri otherwise you'll go on my ignore list
14:30 Trelane Hmm, the documentation for to_json could be explicit about when you'd want to use it instead of encode_json
14:33 basiliscos1 joined #mojo
14:35 meshl joined #mojo
14:36 Trelane hmm, to_json can't be safely used like this: <script>foo = <%= to_json($ds) %></script>
14:39 Trelane because... $ds = { foo => "</script><script>alert('xss')</script>" };
14:40 Trelane one solution would be to turn each "<" into "\u003c"
14:42 jberger_ sri: my apologies, I thought that that had been removed
14:43 Trelane It would be nice to have a function in Mojo::JSON that allows creating JavaScript object literal suitable for putting in web pages
14:46 ryozi joined #mojo
14:53 aramisf joined #mojo
14:56 sri Trelane: that's not how HTML works, <script> has special rules for parsing
14:59 sri wait, you mean specifically that example? "</script><script>alert('xss')</script>"
14:59 Trelane yeah
15:00 sri which framework protects from that?
15:00 Trelane none, but it's a very common mistake people make
15:01 sri this is the first time the topic has come up in this community, it can't be that common
15:03 sri jberger_: although, Trelane is doing a good job of convincing me to_json was a bad idea :)
15:04 sri now feels like we encourage the shitty practice of encoding json into script blocks
15:07 Jonneh joined #mojo
15:10 basic6 joined #mojo
15:11 Jonneh joined #mojo
15:15 Trelane oh, until aug 12 mojo did protect you from </script>
15:15 Trelane But then https://github.com/kraih/mojo/commit/5271482dfbd4d4ba074aaed838e9bb89969da745#diff-ca9694676bc47b6c51420cb2af6591c6 broke that protection
15:16 sri hahahahaha
15:17 sri that's not what it was meant for, and we got weekly complaints about the behavior
15:17 sri literally, people yelling at us for not encoding their json like other encoders do
15:17 Trelane oh the irony
15:18 ignacio_ joined #mojo
15:19 cosimo joined #mojo
15:20 cosimo joined #mojo
15:22 dotan joined #mojo
15:23 sri actually, it appears php encodes forward slashes by default :o
15:23 sri umm
15:23 sri s/encodes/escapes/
15:25 sri lol, and of course they are getting lots and lots of complaints even though it's explained as a security feature!
15:27 sri oh, and i remember where we got it from... it's on the site under "string" http://www.json.org/
15:27 sri but not part of the RFC
15:28 sri oh, actually it is also in the RFC http://tools.ietf.org/html/rfc7159#section-7
15:29 sri but not required
15:48 sri Trelane: you could open an issue with the proposal to bring it back (and expalin the security benefits)
15:49 sri who knows, maybe our users are more security conscious
15:50 sri of course this is bad when you're monkey patching JSON::XS in for a speedup
15:51 KCL_ joined #mojo
15:58 rem_lex| joined #mojo
16:09 jnbek joined #mojo
16:11 howitdo joined #mojo
16:25 whatitdo joined #mojo
16:25 gnephiak joined #mojo
16:35 sri *crickets*
16:35 Mso150 joined #mojo
16:36 Trelane baseball?
16:36 Trelane https://github.com/kraih/mojo/issues/693
16:38 sri you mean 5.28
16:38 sri and to_json was added in 5.48
16:39 sri so it never actually produced \/, just encode_json did
16:40 Trelane well, that obviously was the worse bug report ever
16:40 * Trelane edits
16:40 sri seen worse... sooooo much worse :)
16:43 whatitdo joined #mojo
16:43 Trelane okay, I updated a little.
16:43 Trelane I thought the old encoding gave us "\u002f"
16:45 Trelane oh, //=
16:46 Trelane right, that's a better bug report
16:53 sri labeled and commented
16:58 Trelane When you say "monkey patch them into", do you have an example of that being done?
16:59 sri here's a legacy module https://metacpan.org/pod/Mojo::JSON::XS
16:59 sri jzawodn is working on a better one
17:01 Trelane That module already has special handling of     $string =~ s!\x{2028}!\\u2028!gs;
17:01 Trelane it could add / too
17:01 Trelane (I know that's not ideal)
17:02 sri there's a higher standard for security features
17:02 Trelane well, you could add that logic as a last pass to to_json
17:02 sri if we readd \/ and document it as a security feature, things change
17:03 sri that doesn't change the problem
17:04 sri people will monkey patch JSON::XS::to_json into Mojo::JSON
17:05 * jzawodn dealing with a depoyment today but hope to do the JSON::XS thing before too long
17:05 sri if you're losing u2028 and u2029 handling that may give you an error, but at the end of the day it's harmless
17:06 sri but if you depend on xss protection from \/, well, that's bad
17:06 Trelane maybe we need an explict function
17:07 Trelane then that's a whole new can of worms
17:07 mst jzawodn: recommendation - monkeypatch in Cpanel::JSON::XS instead
17:07 mst jzawodn: you get a much saner upstream at that point
17:07 sri mst: i've already recommended that :)
17:07 jzawodn mst: yeah, sri tipped me off to that
17:07 mst \o/
17:08 * mst is enjoying the slow spread of JSON::MaybeXS across the CPAN
17:08 jzawodn I'm missing something obvious
17:09 jzawodn what's the way to do this http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Post-processing-dynamic-content in a *non* lite app?
17:09 jzawodn (adding some gzip support today)
17:09 disputin joined #mojo
17:09 sri jzawodn: $app->hook(after_render => sub {...
17:10 jzawodn ah, ok.  got it
17:14 basiliscos joined #mojo
17:18 jzawodn yay, works great
17:32 irq joined #mojo
17:41 Mso150 joined #mojo
17:55 jberger__ joined #mojo
17:57 Mso150 joined #mojo
17:58 sri anyone got a google inbox invite for me? :)
17:58 tempire This is the first I've heard of it
17:58 sri http://www.theverge.com/2014/10/22/7039391/google-inbox
18:00 tempire I just booted a machine with mavericks.
18:00 tempire It already looks old and crusty.
18:01 sri hahaha... the new google meme
18:01 sri SHUT UP AND TAKE MY USERDATA
18:02 jberger_ joined #mojo
18:08 Mso150 joined #mojo
18:24 jzawodn this is a stretch, but is there some magic that removes the "Content-Encoding: gzip" header from $t->rx->res->headers when using Test::Mojo?
18:25 jzawodn my app handles the compression stuff fine when I test by hand but I'm having trouble construting a foo.t test that works to verify it
18:32 sri http://mojolicio.us/perldoc/Test/Mojo#request_ok
18:34 jzawodn I see that but I'm not sure how to confirm that my app sent back gzip encoded json rather than uncompressed.  By the time I see it, of course, it is uncompressed.  But I want to peek under the hood and verify that it was compressed.
18:35 jzawodn (if that makes sense)
18:36 jzawodn I can test at the command-line and see the Content-Encoding header and see that the response is binary data.  Just not sure how to do so within the Test::Mojo world.
18:38 ignacio_ joined #mojo
18:39 tempire jzawodn: header_* methods
18:39 tempire You can also look at the previous transaction directly, $t->tx
18:40 jzawodn tempire: yeah, I have a failing test: $t->header_is(Expect => 'Content-Encoding', 'gzip');
18:40 jzawodn I dump the $t->tx->req->to_string and see the Accept-Encoding: gzip header was present
18:41 sri is that a typo?
18:41 sri or did you really use Expect?
18:42 jzawodn not a typo.  I was following http://mojolicio.us/perldoc/Test/Mojo#header_is
18:44 tianon heh
18:44 tianon in the examples there, "Expect" is the header name
18:44 tianon so you want "$t->header_is('Content-Encoding', 'gzip');"
18:44 jzawodn wat
18:44 jzawodn oh shit
18:44 tianon :)
18:44 * jzawodn hangs head in shame
18:45 good_news_everyon joined #mojo
18:45 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/cVq8BQ
18:45 good_news_everyon mojo/master 7ca8325 Sebastian Riedel: use a more common header in test example
18:45 good_news_everyon left #mojo
18:45 tianon :D
18:45 jzawodn thanks sri
18:45 tempire I totally etagged another header.
18:45 sri i had to laugh, but i can see how that might happen
18:46 sri we stopped using Expect for examples a long time ago actually, must have forgotten those 4
18:47 jzawodn yeah, so much of mojo looks like verb => thing
18:48 sri the detecting compression thing is actually harder than it might seem
18:48 sri we completely remove all traces from the transaction
18:48 jzawodn ah, ok... so I'm not totally barking up the wrong tree
18:49 sri there are ways though
18:49 sri you have to hook into events
18:49 sri to get at the header http://mojolicio.us/perldoc/Mojo/Content#body
18:51 sri to get at the actual compressed content http://mojolicio.us/perldoc/Mojo/IOLoop/Stream#read
18:51 jzawodn ok.  I've peeked into a full Data::Dumper'd $tx to see if I could find any clues
18:51 jzawodn ah ha
18:52 sri (second is a bit harder, requires a detour over http://mojolicio.us/perldoc/Mojo/Transaction#connection)
18:53 sri if you feel strongly about this, maybe propose a Mojo::Content::auto_decompress attribute or so
18:53 sri so decompression can be deactivated
18:53 jzawodn ok, I'll give it some thought.  thanks for the clairifcation and doc fix. :-)
18:57 jamesaxl joined #mojo
19:07 Mso150 joined #mojo
19:18 phillipadsmith joined #mojo
19:22 dod joined #mojo
19:22 disputin joined #mojo
19:24 disputin joined #mojo
19:31 good_news_everyon joined #mojo
19:31 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/5DuOkQ
19:31 good_news_everyon mojo/master f2fbc50 Sebastian Riedel: added auto_decompress attribute to Mojo::Content
19:31 good_news_everyon left #mojo
19:31 sri jzawodn: well, now it's there :)
19:31 sri feels right having that attribute, more consistent
20:03 stryx` joined #mojo
20:06 jzawodn oh, wow... awesome.
20:06 jzawodn this is a good reason to upgrade soon :-)
20:22 davido_ joined #mojo
20:25 basiliscos joined #mojo
20:29 Kripton joined #mojo
20:36 good_news_everyon joined #mojo
20:36 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/CMTuMA
20:36 good_news_everyon mojo/master 686418e Sebastian Riedel: fixed typo in test example
20:36 good_news_everyon left #mojo
20:43 davido_ joined #mojo
20:51 Kripton joined #mojo
20:53 aramisf joined #mojo
20:58 rem_lex joined #mojo
21:02 denis_boyun joined #mojo
21:07 tbushell joined #mojo
21:08 tbushell left #mojo
21:22 meshl joined #mojo
22:14 jberger_ joined #mojo
22:17 jberger__ joined #mojo
22:34 marmez joined #mojo
22:36 ryanc joined #mojo
22:43 marmez left #mojo
22:44 marmez joined #mojo
23:06 human39 joined #mojo
23:31 klapperl_ joined #mojo
23:41 bpmedley_ joined #mojo
23:43 klapperl joined #mojo
23:51 marmez Hello.
23:51 marmez My question may be stupid, but... Is it possible to store full objects in Mojolicious sessions? (Yes, I know there is size limit.)
23:53 meshl joined #mojo
23:58 klapperl_ joined #mojo

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