phpbb 10188/10225

part 1

(20:52:30) bantu: naderman: so, how it output buffering?
(20:55:54) naderman: rereading the tickets
(20:55:57) naderman: to make sure I get it right ...
(21:09:20) bantu: uh ff5 in natty
(21:11:22) naderman: this is weird stuff :)
(21:14:42) naderman: can't even manage to reproduce the original issue
(21:14:51) naderman: how did he manage to get the datetime warning to go away
(21:14:56) naderman: but still display the headers stuff
(21:17:43) bantu: naderman: maybe he configured the timezone in php.ini
(21:17:54) naderman: but then I don't get the headers already sent
(21:18:11) bantu: well yeah that's the issue
(21:18:13) naderman: oh wait gzip off
(21:18:15) naderman: maybe that
(21:18:29) naderman: bantu: huh?
(21:18:35) naderman: the issue is that he gets headers already sent errors
(21:18:36) naderman: I don't
(21:19:02) bantu: yes exactly, it's not related to the date/time warning
(21:19:06) naderman: where the heck do you enable gzip
(21:19:11) naderman: bantu: well ok then
(21:19:15) naderman: so how do I reproduce it
(21:19:15) naderman: :D
(21:19:33) bantu: I downloaded his xampp version
(21:19:46) naderman: well I'd like to do this with my regular install
(21:19:51) bantu: there is xampplite
(21:19:54) naderman: so I have a somewhat controlled set of variables ;-)
(21:21:48) bantu: naderman: Server settings
(21:21:51) bantu: right at the top ;-)
(21:21:53) bantu: easy :-P
(21:22:38) bantu: I doubt you'll be able to reproduce without his environment settings.
(21:24:11) naderman: well there must be some way
(21:24:18) naderman: I thought you said you understood this
(21:24:28) naderman: anyway gzip doesn't do anything for me
(21:24:29) ckw [~cwalsh@66.220.144.74] entered the room.
(21:25:16) naderman: bantu: I mean why would it say headers already sent if he configured the timezone
(21:25:21) naderman: if he did there would be no error to begin with
(21:25:25) naderman: so that code would never be executed
(21:25:41) bantu: naderman: well I can tell you the headers sent messages go away after reverting http://tracker.phpbb.com/browse/PHPBB3-10188
(21:25:44) naderman: bantu: you didn't manage to reproduce his problem either, did you?
(21:25:54) bantu: I was able to reproduce
(21:25:56) naderman: bantu: but you do have the actual error message on your board, right?
(21:26:07) naderman: I don't care how you make them go away
(21:26:10) naderman: I want them to be there :P
(21:26:24) bantu: http://tracker.phpbb.com/browse/PHPBB3-10225?focusedCommentId=36076&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36076
(21:26:43) naderman: bantu: but that is not a reproduction?
(21:26:54) naderman: your error message contains
(21:26:54) naderman: [phpBB Debug] PHP Notice: in file /includes/functions_messenger.php on line 403: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead
(21:26:58) naderman: the reporter's does not
(21:26:59) bantu: after that I applied my timezone fix
(21:27:12) naderman: and then you still get the headers already sent?
(21:27:14) bantu: then the first two debug lines go away
(21:27:18) bantu: but still getting headers sent
(21:27:38) naderman: well then why is it executing the error handler?
(21:27:48) naderman: you didn't debug that?
(21:28:03) bantu: nope, I stopped there
(21:28:05) naderman: I mean why would it ever run the error handler if there wasn't an error
(21:28:06) naderman: ah I see
(21:28:17) naderman: bantu: did you use xampp for linux?
(21:28:25) bantu: no windows
(21:29:24) naderman: I guess I'll have to install that then ...
(21:29:37) naderman: wish bug reporters had enough of a clue to debug stuff themselves
(21:29:38) naderman: :D
(21:30:02) bantu: all you have to do is extract the xampplite zip to the root of a partition
(21:30:16) naderman: yeah I just need a windows system first ...
(21:30:32) bantu: oh
(21:30:56) naderman: yuriy's helping ;-)
(21:31:05) bantu: so we somehow end up in the error handler and because ob_get_level() is int(1) > 0, ob_flush() is called
(21:31:10) Marshalrusty: naderman wants to steal my laptop
(21:31:34) bantu: and after that it somehow hides the echo message and returns
(21:31:56) naderman: bantu: well what I care about is why do we end up in the error handler
(21:32:00) naderman: because that makes quite a difference
(21:32:37) A_Jelly_Donut: Marshalrusty, you mean naderman found somehting a mac couldn't do? :P
(21:33:11) bantu: naderman: It's still confusing because it goes away after reverting http://tracker.phpbb.com/browse/PHPBB3-10188
(21:33:13) bantu: o_O
(21:33:16) naderman: bantu: what is xampplite
(21:33:20) naderman: I can only find regular xampp
(21:33:33) naderman: A_Jelly_Donut: I don't have a mac
(21:33:35) bantu: naderman: http://www.apachefriends.org/en/xampp-windows.html
(21:33:50) naderman: bantu: don't see any light version for download there?
(21:34:05) bantu: naderman: oh sorry
(21:34:06) bantu: sec
(21:34:09) A_Jelly_Donut: you had a mac in new york, iirc?
(21:34:18) naderman: A_Jelly_Donut: nope
(21:34:28) naderman: I did have one in London
(21:34:35) A_Jelly_Donut: oh, hm ... :/
(21:34:36) naderman: but that was like ages ago :P
(21:34:39) bantu: naderman: http://sourceforge.net/projects/xampp/files/XAMPP%20Windows/1.7.3/
(21:34:57) bantu: that's his version, but .4 is current
(21:35:08) naderman: I'll take his
(21:36:06) naderman: not downloading >:(
(21:36:23) naderman: now ...
(21:36:39) naderman: wow that is slow
(21:36:43) naderman: < 100kb/s
(21:36:52) nn-: xdebug provides stack traces
(21:37:10) naderman: yes it does
(21:37:11) nn-: but it may not too well with whatever output capturing is going on
(21:37:55) nn-: array xdebug_get_function_stack() http://www.xdebug.org/docs/stack_trace
(21:38:10) nn-: none xdebug_print_function_stack( [ string message ] )
(21:41:45) Noxwizard: naderman: Did you disable output buffering?
(21:42:39) tumba25 left the room (quit: Ping timeout: 276 seconds).
(21:45:29) naderman: Noxwizard: yes
(21:45:43) naderman: also as an empty string
(21:45:55) naderman: didn't do it for me though
(21:46:16) Noxwizard: Does it successfully send the board creation email?
(21:49:50) naderman: didn't check
(21:49:51) naderman: why?
(21:50:05) naderman: as in I didn't even configure email
(21:51:06) Noxwizard: My local ones aren't set up with a mail server, so it triggers an error which is logged in the ACP. I thought that may have been doing it on mine if you had yours properly configured.
(22:04:39) naderman: ah ok cool
(22:04:45) naderman: that's a hint at least ;-)
(22:04:54) naderman: which page is that one sent on?
(22:05:10) naderman: ah yeah
(22:05:12) naderman: the confirmation page
(22:05:14) naderman: as he says
(22:23:22) naderman: oh I think I get it
(22:24:27) naderman: yay success
(22:30:56) bantu: naderman: tell me
(22:31:12) naderman: just posting a comment
(22:35:23) naderman: bantu: posted
(22:35:27) naderman: bantu: http://tracker.phpbb.com/browse/PHPBB3-10225?focusedCommentId=36092#comment-36092
(22:39:32) bantu: naderman: ok
(22:39:37) bantu: possible fix?
(22:39:43) bantu: replace with error_collector?
(22:39:45) naderman: so basically we need to improve the current fix to 10188
(22:39:46) naderman: not sure yet
(22:39:55) naderman: bantu: well not sure if we do this anywhere else
(22:40:17) naderman: otherwise yeah that'd be a solution
(22:40:47) weaverryan [~weaverrya@c-68-53-82-225.hsd1.tn.comcast.net] entered the room.
(22:41:10) naderman: bantu: looking at alternatives
(22:42:13) naderman: I guess we could just check if output_buffering is disabled and then skip the ob_flush in that case
(22:44:55) Marshalrusty|NB left the room (quit: Disconnected by services).
(22:44:58) Yuriy_ [~Yuriy@207-237-244-5.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com] entered the room.
(22:46:29) naderman: hmm but that brings us back to the original thing
(22:47:48) naderman: bantu: I think I need to wait for nn- because I don't get the problems with compression
(22:47:59) naderman: I mean I'd basically revert to what we had before
(22:48:04) naderman: but clearly there was a problem with that too
(22:48:30) bantu: hmm
(22:48:53) bantu: using error_collector sounds a lot less hacky than what we currently have
(22:49:08) naderman: yes
(22:49:18) naderman: we just need to make sure that's used everywhere where we do this
(22:49:18) nn-: ?
(22:49:26) naderman: nn-: see http://tracker.phpbb.com/browse/PHPBB3-10225?focusedCommentId=36092#comment-36092
(22:49:46) bantu: grep "ob_start(" . -R | grep -v "\~:" | wc -l
(22:49:47) bantu: 10
(22:49:53) naderman: and technically the current if (ob_get_level() < 0) is not really correct
(22:50:04) naderman: but I doubt any MOD really uses that
(22:50:20) naderman: so if we just make sure we use the error collector internally we'd be fine

part 2

(10:53:46) bantu: nn-: looks like he was aware of catching errors with ob_start https://github.com/phpbb/phpbb3/commit/374093d6152ff9ff2b232311bfeeafca43a27915
(10:54:25) bantu: the !ob_get_level()) { @ob_flush(); } part doesn't look right either

part 3

(12:29:45) rxu: bantu : poke
(12:29:56) bantu: rxu: ?
(12:30:09) bantu: brb
(12:30:33) rxu: what is 'output_buffering' value for your installation(s) where you're reproducing 10225?
(12:35:26) bantu: rxu: The Windows or Ubuntu system?
(12:36:21) rxu: both
(12:36:56) bantu: oh sorry
(12:37:00) bantu: missed the (s)
(12:37:28) rxu: probably I missed 'are' and valu_s_ :P
(12:41:27) bantu: rxu: http://tracker.phpbb.com/browse/PHPBB3-10225?focusedCommentId=36103&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36103
(12:42:21) nickvergessen left the room (quit: Quit: Leaving.).
(12:55:40) rxu: bantu : replied
(12:57:29) bantu: rxu:  ob_get_level() is int(1) so it is caught
(12:57:33) bantu: not on 3.0.8
(12:57:40) bantu: but on 3.0.9 which I am testing on
(12:58:32) rxu: I mean you mentioned the issue was gone with 10188 reverted
(12:58:47) rxu: fix* reverted
(12:59:17) bantu: yes it is gone after reverting 10188 on windows
(12:59:39) bantu: because output_buffering is off there and ob_flush() isn't called
(13:00:15) rxu: but actually output buffer is enabled because of ob_start() call
(13:00:35) rxu: I think 10188 fix has made output_buffer state detection correct so we can see more errors now
(13:00:58) rxu: err, output buffer, not ini value
(13:01:22) rxu: I think that's because of echo call before page_header() call
(13:18:52) rxu: bantu : another thing, if output buffer is on, ob_flush() is gonna be called twice (the second time is in exit_handler())
(13:19:16) rxu: not sure what is it for
(13:22:31) bantu: rxu: no (ob_get_level() > 0) ? @ob_flush() : @flush();
(13:22:51) bantu: that's in exit_handler
(13:23:02) bantu: and calling ob_flush once will decrease ob_get_level() by one
(13:24:24) rxu: do we have nested buffer levels?
(13:26:11) bantu: ah right
(13:26:17) bantu: that's a theoretical issue, yes
(13:26:59) rxu: I mean we probably can get rid of ob_flush call in msg_handler
(13:27:18) rxu: because it'll be called in exit_handler anyway
(13:30:04) bantu: rxu: I agree
(13:30:35) rxu: if we do, 10225 issue will be gone :)

part 4

(14:45:02) nn-1: well the issue is that our msg_handler produces output
(14:45:09) nn-1: because of that it necessarily flushes
(14:45:25) nn-1: we need a pair of functions to collect both output and errors instead of ob_start/ob_end
(14:47:19) nn-1: ... and this might fall apart if msg_handler calls exit for any reason
(14:47:27) nn-1: this is such a failure

part 5

(15:48:41) bantu: [19:23:25] <bantu> and calling ob_flush once will decrease ob_get_level() by one <-- wrong
(16:01:20) naderman: indeed it'll leave it alone

part 6

(19:01:29) bantu: nn-1: were you finally able to reproduce?
(19:01:50) bantu: naderman: go merge http://tracker.phpbb.com/browse/PHPBB3-7729?
(19:02:13) naderman: yes
(19:05:38) bantu: hmm
(19:05:41) bantu: what does that do? $now = getdate(time() + $user->timezone + $user->dst - date('Z'));
(19:06:34) bantu: getdate() transforms a timestamp into an array
(19:06:57) naderman: bantu: where is that from?
(19:07:00) bantu: index
(19:07:17) bantu: so it doesn't rely on a timezone at all when you pass timestamp in
(19:07:28) naderman: ah yeah it's for birthdays isn't it?
(19:07:29) bantu: and thus shouldn't throw this timezone error at all
(19:07:32) bantu: naderman: yes
(19:07:36) naderman: well it uses date()
(19:07:41) naderman: which throws the error regardless
(19:07:49) bantu: sure
(19:08:05) bantu: but getdate() throws the error which is a php bug IMO
(19:08:16) bantu: next question is use of date()
(19:08:32) naderman: bantu: "Returns an associative array containing the date information of the timestamp, or the current local time if no timestamp is given. "
(19:08:37) naderman: the latter requires the setting
(19:08:37) bantu: and whether that will break if we set a timezone unequal to UTC
(19:08:45) naderman: so they just throw the warning whenver you use that function
(19:08:49) naderman: seems perfectly reasonable to me
(19:09:14) naderman: bantu: it will break in so far as that it might be different from what the actual time is
(19:09:25) naderman: but there is no way to circumvent that for us
(19:09:43) bantu: there is
(19:09:49) naderman: ?
(19:10:09) bantu: call date_default_timezone_set('UTC'); instead of date_default_timezone_set(@date_default_timezone_get());
(19:10:14) naderman: no
(19:10:21) naderman: because UTC is more likely to be wrong
(19:10:26) naderman: than date_default_timezone_get()
(19:10:50) naderman: I don't understand what we are discussing here
(19:10:53) naderman: your fix works, it's fine
(19:10:57) naderman: I'll merge and we move on?
(19:11:00) bantu: ok
(19:12:18) bantu: I mean phpBB should not rely on any timezone assumptions at all.
(19:12:54) naderman: well then you are saying we should just display the warning and exit
(19:13:05) naderman: which is not nice from a usability perspective
(19:13:13) naderman: so instead we make a timezone assumption
(19:13:19) bantu: nah
(19:13:26) bantu: we have our own timezone handling
(19:13:36) naderman: our timezone handling is not independent of the system
(19:13:58) bantu: why is that?
(19:13:58) naderman: the entire get time in gmt thing only ever works if PHP is configured so that it knows what GMT is
(19:14:20) naderman: cause otherwise we have no way of telling what timezone the time we get from the system is in to begin with
(19:14:31) naderman: we don't have our own clock
(19:14:36) naderman: we rely on the system to provide us with a time
(19:14:42) naderman: which we convert into utc to make things easier
(19:14:52) naderman: but that whole conversion depends on what PHP tells us the system timezone is
(19:15:32) naderman: bantu: understood?
(19:16:45) bantu: naderman: would have to further look into the issue
(19:16:53) naderman: why?
(19:17:01) naderman: it's really not that complicated
(19:17:29) naderman: which part don't you understand?
(19:18:26) naderman: bantu: actually the comment in your patch is wrong
(19:18:31) naderman: shall i fix it, or do you want me to?
(19:18:39) bantu: lol
(19:18:42) bantu: what is wrong?
(19:18:59) naderman:   	136 	
(19:18:59) naderman: +  // So what we basically want to do is set our timezone to UTC,
(19:19:00) naderman: we don't
(19:19:03) maelsoucaze left the room (quit: ).
(19:19:09) naderman: we want the timezone to be set to the correct system timezone
(19:19:20) naderman: so that we can correctly retrieve UTC time values from its non-UTC time
(19:19:54) naderman: that's why we use date_default_timezone_get because it might guess the right timezone
(19:20:04) naderman: which has a higher chance of being correct than just assuming UTC
(19:20:16) bantu: there is no difference for us
(19:20:23) naderman: yes there is a very big one
(19:20:32) naderman: if the user ever actually sets the correct timezone
(19:20:36) naderman: suddenly all times are off
(19:20:40) bantu: no
(19:20:42) naderman: because we assumed the timezone to be UTC
(19:20:45) naderman: when it really wasn't
(19:20:49) naderman: yes
(19:21:12) naderman: bantu: it works as follows
(19:21:21) naderman: we use a function like time() to retrieve a timestamp
(19:22:03) naderman: which gives us something timezone independent according to the system
(19:22:27) naderman: so in that case everything works fine
(19:22:40) naderman: but we also use other means of getting the current time like date() which isn't
(19:23:00) naderman: now I'm confused
(19:23:05) naderman: that uses time() as the default
(19:28:56) naderman: hmm that date('Z') thing is interesting
(19:31:43) naderman: it does seem to work correctly
(19:32:43) naderman: ah of course bantu: getdate() depends on the local system time
(19:32:55) naderman: it takes a UTC timestamp
(19:33:07) naderman: and outputs the info like day/month etc. based on local timezone
(19:33:18) naderman: and there is no equivalent function that simply works in UTC
(19:33:40) naderman: so we subtract date('Z') before calling it, so that the result is the same it would be if there was a gmgetdate() function
(19:35:08) bantu: okay
(19:35:09) bantu: makes sense
(19:35:27) naderman: so I guess I'm wrong
(19:35:34) naderman: because it then doesn't matter what the timezone is
(19:35:38) bantu: exactly
(19:35:41) bantu: ;-)
(19:35:44) naderman: because getdate() and date('Z') balance each other out
(19:35:59) naderman: well alright then
(19:36:03) naderman: I'll just merge your patch :)
(19:37:29) bantu: needs a wrapper function with comments
(19:38:22) naderman: well merged :P
(19:38:24) naderman: too late ^_^
(19:38:52) bantu: not in 3.0.9
(19:38:57) bantu: and maybe not in 3.0
(19:39:00) bantu: so fine
(19:40:04) naderman: heh
(19:40:11) naderman: yeah can always still do that some other time
(19:40:21) bantu: it's used 4 times
(19:40:22) bantu: so 3.0
(19:40:39) erik|iOS [~erikfrere@phpbb/support/erikfrerejean] entered the room.
(19:40:40) mode (+o erik|iOS) by ChanServ
(19:42:27) bantu: messenger calls date('r', time())
(19:42:30) bantu: by the way
(19:43:07) naderman: so?
(19:43:26) naderman: oh
(19:43:29) naderman: should use gmdate you mean?
(19:43:33) naderman: well it includes the timezone
(19:43:38) naderman: so doesn't really matter
(19:43:46) naderman: probably even better this way
(19:43:48) bantu: date is better
(19:43:50) naderman: so emails are sent from server timezone
(19:43:51) naderman: yeah
(19:43:51) bantu: string(31) "Sun, 26 Jun 2011 01:43:23 +0200"
(19:43:52) bantu: string(31) "Sat, 25 Jun 2011 23:43:23 +0000"
(19:43:55) naderman: yup
(19:44:09) bantu: it doesn't matter
(19:44:26) bantu: and we're screwed anyway if the server doesn't know it's timezone
(19:44:39) bantu: which it should really know considering recent OSes
(19:45:42) naderman: heh yeah
(19:47:17) bantu: this wrapper is really neat
(19:47:29) bantu: the others on php.net are multiple lines
(19:56:11) t_backoff [~t_backoff@phpbb/support/tbackoff] entered the room.
(19:56:12) mode (+o t_backoff) by ChanServ
(19:57:14) erik|iOS left the room (quit: Quit: Colloquy for iPod touch - http://colloquy.mobi).
(20:14:13) bantu: coppa has a similar trick
(20:14:14) bantu: 				$now = getdate();
(20:14:15) bantu: 				$coppa_birthday = $user->format_date(mktime($now['hours'] + $user->data['user_dst'], $now['minutes'], $now['seconds'], $now['mon'], $now['mday'] - 1, $now['year'] - 13), $user->lang['DATE_FORMAT']);
(20:19:13) Derky left the room (quit: ).
(20:35:16) naderman: maybe we should add a function for this at some point ;-)
(20:35:24) tumba25 left the room (quit: Read error: Operation timed out).
(20:36:33) nn-1: phpbb should not care what timezone is active
(20:37:17) nn-1: we set the "current" timezone for the benefit of whatever modifications/third party code that might expect a certain timezone, either local (i.e. not utc) or a timezone they set
(20:42:01) nn-1: bantu: probably yes but i had to leave
(20:42:04) nn-1: looking at it now 
(20:54:32) naderman: nn-1: yeah we figured the timezone thingy out
(20:54:48) naderman: only thing that's really left is coming up with a working solution to the output buffering thing

part 7

(21:05:43) nx-: looks like reproduce code is not reproducing
(21:06:22) nx-: http://trashb.info/a9aac6a9
(21:08:23) nx-: http://trashb.info/6e2aceb9
(21:08:48) nx-: so 1/0 is a notice?
(21:09:47) nx-: or is that change not in rc2
(21:15:19) naderman: it is not in rc2
(21:15:34) naderman: nx-: also test it in a browser
(21:15:49) naderman: output buffering gets properly disabled on the console automatically
(21:16:11) nx-: k
(21:17:15) nx-: in a browser something broke in a major way
(21:19:01) nx-: http://108.35.7.206:8071/boards/a111/test1.php
(21:19:17) nx-: do you see junk at the end?
(21:20:18) nx-: aside from that even in browser i am not getting headers already sent
(21:20:33) naderman: yeah i see the junk
(21:20:37) naderman: is this with gzip enabled?
(21:20:49) naderman: if so, disable it :)
(21:22:34) nx-: i think i was under the impression that ob_flush did not flush the output buffer itself
(21:22:41) nx-: it merely flushed output to output buffer
(21:22:50) nx-: and this seems to be consistent with behavior i am seeing here
(21:23:10) naderman: what are your settings
(21:23:16) nx-: http://trashb.info/6de30109
(21:23:19) naderman: because it quite definitely flushes to the browser for me
(21:23:34) nx-: which settings are you referring to?
(21:23:40) naderman: output_buffering for one
(21:23:45) naderman: gzip related ones
(21:23:54) naderman: which version of php?
(21:24:43) naderman: do you have an output_handler set?
(21:24:55) naderman: is implicit_flush on or off?
(21:26:14) nx-: on a new board where i can access acp...
(21:26:18) nx-: gzip is off in phpbb
(21:26:54) nx-: http://108.35.7.206:8071/boards/t2/
(21:26:55) nx-: admin/1
(21:27:55) nx-: output buffering is 4096
(21:28:04) nx-: output handler is ob_gzhandler
(21:28:08) naderman: set output_buffering to an empty string
(21:28:11) nx-: in php.ini
(21:28:17) naderman: set the output_handler to Off
(21:29:04) naderman: or rather
(21:29:10) naderman: just don't set it at all
(21:29:16) naderman: and make sure
(21:29:17) naderman: zlib.output_compression = Off
(21:29:27) nx-: that was already off
(21:29:29) naderman: k
(21:29:44) nx-: ok now i get it
(21:30:26) naderman: yay ^_^
(21:30:30) naderman: (or not)
(21:30:57) naderman: so not quite sure why ob_flush actually flushes then
(21:31:13) nx-: is there a definite answer why msg handler flushes?
(21:31:22) naderman: well yes
(21:31:27) naderman: because it calls ob_flush
(21:31:32) naderman: if ob_get_level() > 0
(21:31:35) nx-: why does it call ob_flush
(21:31:37) naderman: if you comment out that line it doesn't
(21:31:47) naderman: because ob_get_level() is > 0
(21:31:56) nx-: yes, why does it have that entire logic in there?
(21:31:59) naderman: because you called ob_start() before the line that caused the error
(21:32:08) naderman: nx-: I don't know
(21:32:13) naderman: I thought you did
(21:33:02) naderman: it says
(21:33:03) naderman: "// flush the content, else we get a white page if output buffering is on"
(21:33:22) naderman: so i guess test it with output buffering on and with the line removed
(21:33:25) naderman: to see what happens then
(21:34:36) nx-: does php flush if output buffering is started in script and exit is called?
(21:35:43) nx-: ob_start(); echo 'start'; exit; produces 'start'
(21:36:23) naderman: but if you enable gzip that results in broken compression
(21:36:24) naderman: :)
(21:36:59) nx-: enable gzip where?
(21:37:16) naderman: I enabled it in phpBB
(21:37:23) naderman: will try in php.ini now
(21:38:13) naderman: using output_handler and without the ob_flush works fine
(21:38:29) nx-: http://trashb.info/85ac2c35 still produces start with phpbb gzip on
(21:38:47) naderman: oh I see why, phpbb also does the ob_flush explicitly when phpbb has gzip on
(21:39:27) naderman: nx-: ok
(21:39:28) naderman: so?
(21:39:31) nx-: so when gzip and buffering is off everywhere
(21:39:41) nx-: we get the headers sent thing
(21:39:48) nx-: when buffering is on we don't
(21:40:29) naderman: yup
(21:40:45) naderman: cause in one case ob_flush results in flush to browser in the other only to output_buffer
(21:42:26) naderman: nx-: so again I wonder the same as Andreas
(21:42:47) naderman: what would have been the problem with simply checking if output_buffer is >= 1 instead of === 1?
(21:43:27) nx-: i'm still trying to determine what is really going on here
(21:43:34) naderman: heh alright
(21:43:56) nx-: with ob msg handler calls ob_flush
(21:44:01) nx-: that somehow makes things work
(21:44:48) naderman: ob_flush flushes the content of the current buffer to the one on the lower level
(21:44:59) naderman: with output_buffering it goes to PHP's global output buffer
(21:45:08) naderman: without output_buffering it is actually flushed over network
(21:45:27) nx-: http://trashb.info/c69fe322 yields 1 in case of headers sent error
(21:45:41) naderman: yes
(21:45:48) naderman: because there is the ob_start() before the error occurs
(21:45:54) naderman: so the ob_get_level() is 1
(21:45:59) nx-: right
(21:46:20) nx-: in this case phpbb flushes when ob is requested outside of phpbb, essentially
(21:46:42) naderman: not sure what you mean by that
(21:47:11) naderman: ob_get_level() does not increase at all when output_buffering is on
(21:47:23) naderman: really I just think that fix of yours replacing it with ob_get_level() was wrong?
(21:47:28) nx-: assuming ob_flush writes output and kills output buffer
(21:47:38) nx-: someone outside of phpbb called ob_start, they want to collect output
(21:47:40) naderman: it does not kill any output buffer
(21:47:43) nx-: (in this case test*.php)
(21:47:57) naderman: ah ok
(21:47:58) nx-: then phpbb msg handler writes output to network
(21:48:04) naderman: yes
(21:48:16) naderman: which it isn't supposed to do
(21:48:21) nx-: ob_flush does not stop that output buffering level
(21:48:25) nx-: it just sends over network in this case
(21:48:28) naderman: yeah
(21:48:38) naderman: well it flushes to the above output buffering level
(21:48:40) nx-: which is contrary to what external-to-phpbb-code requested
(21:48:44) naderman: if there is none it is sent over network
(21:48:48) naderman: yup
(21:48:54) naderman: so ob_flush in general seems like a bad idea
(21:49:41) nx-: now question #1 is what was the previous behavior and #2 is still why msghandler flushes
(21:50:50) nx-: previous behavior was msghandler flushing if output buffering was configured in php.ini
(21:50:59) naderman: well if I remove ob_flush() then firefox tells me
(21:50:59) naderman: Content Encoding Error
(21:50:59) naderman:       
(21:50:59) naderman:       
(21:50:59) naderman:       
(21:51:00) naderman:       
(21:51:02) naderman:       
(21:51:05) naderman:         
(21:51:07) naderman:         
(21:51:09) naderman:           
(21:51:11) nx-: and we can revert to that by doing > 1 check on ini_get
(21:51:11) naderman: The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
(21:51:16) naderman: oops
(21:51:20) naderman: yes
(21:51:43) nx-: so that should be safe-ish if we don't have any better ideas
(21:51:57) naderman: hmm but I still get the headers already sent error in that case
(21:51:57) naderman: weird
(21:52:20) nx-: someone else wants me
(21:52:33) nx-: are you planning to be up for much longer?
(21:52:36) naderman: yeah
(21:52:42) naderman: ^^
(21:52:47) nx-: let's get back to this in an hour or so?
(21:52:49) naderman: sure
(21:53:11) nx-: alright
(21:54:33) naderman: ah no the headers already sent thing was my mistake
(21:55:46) naderman: ok and my remark about ob_get_level() was wrong too
(21:55:55) naderman: ob_get_level is actually incremented with output_buffer on
(21:58:59) naderman: ok it works perfectly if I replace the check with ob_get_level() > 2
(21:59:56) naderman: tested with output_buffer, output_buffer & output_handler, output_buffer & phpbb gzip, output_buffer off & output_handler, output_buffer off & phpbb gzip, output_buffer off
(22:00:19) naderman: question is what that means for the case you described of some other application embedding phpbb within an ob_start/ob_get_clean
(22:05:19) rxu [~Miranda@phpbb/developer/rxu] entered the room.
(22:05:20) mode (+o rxu) by ChanServ
(22:18:24) naderman: ah but that still flushes the first error when a second one occurs
(22:18:38) naderman: really we should just not flush at all and fix that compression error in some other way
(22:19:46) naderman: start[phpBB Debug] PHP Warning: in file /ob.php on line 12: Division by zero
(22:19:46) naderman: content[phpBB Debug] PHP Notice: in file /ob.php on line 13: Undefined variable: b
(22:19:46) naderman: end
(22:19:47) naderman: hmm
(22:20:04) naderman: right
(22:38:43) rxu: naderman : hey. We discussed it with bantu lately. Do we really need to call ob_flush twice: 1st time in msg_handler and 2nd time in exit_handler?
(22:38:59) rxu: isn't the latter call enough?
(22:53:14) nx-: back
(22:53:40) nx-: oh wow, that was 1 hour and 1 minute :)
(22:56:10) nx-: so, we're ok as long as we don't flush the top level
(22:56:18) nx-: you cannot buffer header calls
(22:56:26) nx-: so people who buffer output should not be calling header
(22:57:08) nx-: and conversely any headers calls ought to be either at top level or in code that assumes itself to be responsible for top level
(22:57:36) rxu: nx- : how many buffer levels are there in phpBB?
(22:57:52) nx-: i'm guessing more than reasonably needed by anyone
(22:58:00) nx-: you just nest ob_start calls
(22:58:46) rxu: where?
(22:58:58) nx-: well
(22:59:00) rxu: I can see only 1 in page_header()
(22:59:08) nx-: if there's e.g. ob_gzhandler involved that is one level
(22:59:15) nx-: if you then manually do ob_start this is the second level
(22:59:35) nx-: phpbb should do buffering in error collector
(22:59:39) rxu: so, we're talking about MODs?
(22:59:48) nx-: i think bantu? did a count of ob_* or ob_start and there are 10-ish occurrences
(23:00:15) nx-: apparently the failure can happen on vanilla phpbb if email fails
(23:00:21) rxu: occurences or sequential calls? :)
(23:00:47) nx-: phpbb should be no more than 1 or 2 levels deep
(23:01:07) nx-: there's gzip compression and either templates or error collector which normally can't be active simultaneously
(23:01:10) DavidIQ|- [~iqpad@2001:0:4137:9e76:4dc:23e5:b981:42dd] entered the room.
(23:01:20) rxu: nx- : we call ob_flush() twice for e-notice case
(23:01:24) rxu: why?
(23:01:53) DavidIQ|iPad left the room (quit: Ping timeout: 252 seconds).
(23:01:53) DavidIQ|- is now known as DavidIQ|iPad
(23:01:53) nx-: in msghandler?
(23:02:02) nx-: only one of those calls can happen
(23:02:05) rxu: msg_handler+exit_handler
(23:02:42) rxu: isn't exit_handler enough?
(23:03:04) nx-: well msg handler does not exit on notice
(23:03:14) rxu: yes
(23:03:38) nx-: so between msg handler and exit handler there may be other output
(23:03:43) DavidIQ|iPad left the room (quit: Changing host).
(23:03:43) DavidIQ|iPad [~iqpad@phpbb/manager/DavidIQ] entered the room.
(23:03:50) DavidIQ|iPad left the room.
(23:04:02) DavidIQ|iPad [~iqpad@phpbb/manager/DavidIQ] entered the room.
(23:04:02) mode (+o DavidIQ|iPad) by ChanServ
(23:04:29) nx-: i would like to see some reproduce code for compression failures and/or white pages without flushing
(23:05:33) nx-: what does ob_flush do when not at top level?
(23:05:54) rxu: what code was added later: msg_handler flush or exit_handler flush?
(23:06:04) rxu: send the buffer to the output?
(23:06:09) nx-: This function will send the contents of the output buffer (if any). If you want to further process the buffer's contents you have to call ob_get_contents() before ob_flush() as the buffer contents are discarded after ob_flush() is called.
(23:06:31) nx-: well, apparently not
(23:06:54) nx-: what if we're 2 levels deep into output buffering and ob_flush is called
(23:07:07) nx-: does it flush the innermost buffer to the outer buffer?
(23:07:29) nx-: it says the innermost buffer contents will no longer be available
(23:07:36) nx-: sounds like that should break something
(23:12:10) nx-: xdebug is getting in the way...
(23:13:37) nx-: http://trashb.info/f291f584
(23:14:05) naderman: re
(23:14:55) nx-: that's kind of hard to read but ob_flush ruins output capture by the inner ob calls
(23:15:12) naderman: actually got to go for a few more mins
(23:15:16) naderman: will finish this after
(23:18:08) nx-: overall i think this means people can't wrap phpbb in output buffering reliably
(23:18:22) nx-: given the current logic
(23:18:50) nx-: but then phpbb can do header calls as well, which per earlier are domain of top-level code
(23:19:23) nx-: we have to call ob_flush before flush, i.e., we can't replace ob_flush with flush
(23:19:53) nx-: i'm guessing the reason 10188 was done was for the case of ob_gzhandler
(23:20:02) nx-: which sets up output buffering without affecting ini vars
(23:20:13) nx-: and in that case we cannot flush, we have to ob_flush
(23:20:24) nx-: and i think this was reproducible corruption
(23:20:47) nx-: but, ob_flush ruins output capture
(23:20:50) nx-: hmm
(23:21:59) nx-: i think what we have to do is not flush at all if ob level > 0
(23:22:13) nx-: as any flushing will ruin things in that situation
(23:22:29) nx-: that would be ob level external to phpbb
(23:22:38) nx-: therefore if phpbb gzip is enabled the check should be ob level > 1
(23:35:40) naderman: re
(23:35:45) naderman: properly now
(23:36:36) naderman: nx-: yes I agree
(23:36:42) nn-1: may be useful to do an audit of output buffering usage in phpbb
(23:36:47) You are now known as nn-
(23:36:57) naderman: well the usage in phpbb is one thing
(23:37:13) naderman: as you pointed out MODs and other apps embedding phpbb are a concern
(23:37:34) naderman: all we can do for those is keep it as similar to the current behaviour as possible I guess
(23:38:01) naderman: which doesn't make a whole lot of sense though, since it's already broken for various cases with the current code
(23:38:03) nn-: my theory is current (3.0.8 i'm guessing is what you meant) behavior is broken
(23:38:23) naderman: yes it i
(23:38:24) naderman: *it is
(23:39:07) Sadin-mobile [~rooms@h148.160.101.208.ip.windstream.net] entered the room.
(23:40:03) naderman: nn-: so the way I see it is that the code in functions.php should be reduced to only have the gzip part
(23:40:06) naderman: which can be left as is
(23:40:23) naderman: ah no
(23:40:26) naderman: that didn't work either
(23:40:27) naderman: gah
(23:40:51) naderman: what happens if we remove that entire flushing code from msg_handler?
(23:41:28) nn-: this is where the audit part comes in
(23:41:33) nn-: ;)
(23:42:10) nn-: i don't see why we should flush before exit/gzip compression at all
(23:42:29) nn-: clearly we should not have any unbalanced ob calls
(23:42:58) naderman: alright I guess I'll just comment out that entire section of code and look for problems
(23:43:01) nn-: s/before/other than immediately before/
(23:43:04) naderman: to see what we actually need that for to begin with
(23:44:01) nn-: now i'm getting more curious about this 
(23:44:08) Sadin-mobile left the room (quit: Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi).
(23:44:13) nn-: how is ob_gzhandler managing to work if we ob_flush in exit handler?
(23:45:06) naderman: ob_flush does compress data with ob_gzhandler
(23:45:39) nn-: ob_flush is supposed to trash the buffer
(23:45:55) nn-: or rather send it out to higher level
(23:46:09) nn-: by the time ob_gzhandler calls ob_get_contents there should not be any contents left
(23:46:36) nn-: going to check source
(23:47:28) naderman: ob_gzhandler is a callback function
(23:47:34) naderman: it is called on any ob_flush() afaik
(23:49:30) nn-: that's nice
(23:49:36) nn-: anything like that available to userland?
(23:51:10) nn-: ob_gzhandler is pretty unlike anything else
(23:51:16) nn-: i'm guessing the answer is no
(23:51:27) nn-: Note:              Only built-in functions can be used with this directive. For user       defined functions, use ob_start().           
(23:51:30) nn-: for output_handler
(23:51:47) nn-: so how's this for a test
(23:51:57) nn-: wrap phpbb in a ob_start/ob_end_clean/gzip compress sequence
(23:52:08) nn-: it should fail miserably with 3.0.8
(23:54:05) naderman: haven't tried that with 3.0.8 yet
(23:54:19) nn-: duh. http://us.php.net/ob_start does support a callback argument
(23:54:24) naderman: yes
(23:54:39) naderman: we do even pass ob_gzhandler to ob_start ourselves
(23:54:43) nn-: so ob_start/ob_end_flush is wrong when inner code flushes
(23:54:45) naderman: if phpbb's gzip is enabled
(23:54:54) naderman: what?
(23:55:03) nn-: the correct usage is ob_start(callback) followed by ob_flush and ob_end
(23:55:21) nn-: yeah i screwed that up
(23:55:27) naderman: ob_start without a callback and then ob_get_clean is just as good?
(23:55:31) nn-: ob_start/ob_get_clean is wrong
(23:55:43) naderman: why?
(23:55:49) naderman: that's not wrong?
(23:55:55) nn-: ob_start(callback)/ob_flush/ob_end_clean is right
(23:56:01) naderman: that is different
(23:56:03) naderman: not "right"
(23:56:16) naderman: the two do something very different from each other
(23:56:22) naderman: ob_flush is for when you want to output
(23:56:24) nn-: for capturing output it is wrong
(23:56:27) naderman: ob_get is if you want to store in a variable
(23:56:37) naderman: ob_get_clean is just an abbreviation
(23:56:44) naderman: no it's not wrong
(23:56:47) nn-: if ob_flush is called between ob_start and ob_get_clean, ob_get_clean gets nothing
(23:57:11) naderman: yes
(23:57:19) naderman: ob_flush is not supposed to be called randomly
(23:57:47) nn-: well, yes
(23:57:59) naderman: sure it'd be safer if you also specified a callback and concatenated the result of that with ob_get_clean result
(23:58:02) nn-: http://tracker.phpbb.com/browse/PHPBB3-10225?focusedCommentId=36102&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36102 is essentially wrong usage since msg_handler can ob_flush
(23:58:11) nn-: so that's an invalid reproduce case
(23:58:18) naderman: yes, but the answer is not it is wrong usage
(23:58:23) naderman: the answer is msg_handler should not flush
(23:58:59) nn-: i don't see why msg_handler should flush
(23:59:04) naderman: nn-: and it's not invalid because we do this in phpbb
(23:59:36) nn-: however i don't know why that code was put in, so hmm
(23:59:44) nn-: ah, but
(23:59:50) naderman: so I'd prefer we could get rid of the ob_flush
(23:59:53) nn-: will callback prevent output being sent up?
(23:59:58) naderman: in which case everything would be fine
(06/26/11 00:00:03) naderman: nn-: no
(00:00:09) naderman: it'll just be passed through the callback first
(00:00:42) naderman: how do I decompress a compressed http body
(00:00:51) nn-: it can return '' though
(00:00:58) nn-: i wonder if php will flush ''
(00:01:10) naderman: yes
(00:01:20) naderman: that is the problem in the bug report actually
(00:01:27) naderman: because the content being flushed is empty
(00:01:27) nn-: that's kind of crappy then
(00:01:41) naderman: otherwise we wouldn't have the problem to begin with
(00:02:50) nn-: so
(00:03:02) nn-: if there is one level of output buffering active and someone calls ob_flush
(00:03:22) nn-: after that event headers cannot be set
(00:03:25) nn-: right?
(00:03:31) naderman: yes
(00:04:55) ***nn- going to blame ob_start calls
(00:05:17) Dicky left the room (quit: Read error: Connection reset by peer).
(00:05:45) Dicky [~Dicky@h69-131-100-87.wltonh.dsl.dynamic.tds.net] entered the room.
(00:05:45) Dicky left the room (quit: Changing host).
(00:05:45) Dicky [~Dicky@phpbb/support/Dicky] entered the room.
(00:05:45) mode (+o Dicky) by ChanServ
(00:06:14) nn-: ok, so mail thing forces output due to msg handler flushing
(00:06:31) naderman: yes
(00:06:56) nn-: there is only ob_* stuff to capture output
(00:07:29) nn-: https://github.com/phpbb/phpbb3/blob/develop-olympus/phpBB/includes/error_collector.php does it via error handler
(00:07:33) nn-: which bypasses flushing
(00:07:45) naderman: yes
(00:07:52) nn-: the errors are meant to go through error handler, right?
(00:08:00) nn-: there is no need to add output capture to error collector
(00:08:09) naderman: what?
(00:08:16) naderman: which errors?
(00:08:26) naderman: you mean the mail ones?
(00:08:27) nn-: so the solution would be to replace broken error capture in functions_messenger with error collector usage
(00:08:32) naderman: yes those are sent to the error handler
(00:08:44) naderman: nn-: yes that would work
(00:08:53) naderman: nn-: but it would potentially leave MODs broken
(00:08:55) nn-: was this option on the table already?
(00:08:58) naderman: yes
(00:09:24) nn-: why would mods break?
(00:09:29) naderman: but what this essentially means is that any use of ob_* before sending headers in any MOD is broken
(00:09:50) naderman: because anything triggering the error_handler would cause this error
(00:09:58) naderman: msg_handler
(00:10:04) naderman: now we could either say we accept that
(00:10:11) naderman: or try to get rid of the flushing in msg_handler
(00:10:19) nn-: (any mod problem seems to be separate from this issue of misuse of output buffering for error collection by messenger)
(00:10:51) nn-: you can't use ob for error collection given our msg handler
(00:11:09) nn-: if any mod does that they need to use error collector instead
(00:11:16) naderman: well yes it's one thing to do this intentionally
(00:11:29) naderman: but you might also unintentionally come across an error in output buffered code
(00:11:48) naderman: which would have the headers already sent errors
(00:11:53) naderman: without a good reason for it
(00:12:09) naderman: but I guess we could just ignore that
(00:12:14) naderman: afterall that shouldn't happen anyway
(00:12:16) nn-: uhh did not parse
(00:12:21) naderman: heh
(00:12:26) nn-: (00:11:29) naderman: but you might also unintentionally come across an error in output buffered code - which code?
(00:12:33) naderman: the MODs code
(00:12:41) naderman: could cause an error without the author knowing about it
(00:12:52) naderman: but he wrapped the code in output buffering for some other reason
(00:12:58) naderman: now he gets headers already sent errors
(00:12:59) nn-: you are basically concerned with the same issue appearing in mods and us breaking it by adding more flushing in msg handler
(00:13:14) nn-: and then the question is why does msg handler flush at all
(00:13:19) naderman: yes
(00:13:45) naderman: if we can find a good reason why msg_handler needs to flush at all I'm happy with the error_collector solution
(00:13:52) naderman: but otherwise I'd rather just remove the flushing
(00:13:56) nn-: so, possible approach: 1. fix email code to use output collector and 2. check ini vars only for flushing, but verify that whatever 10188 fixed stays fixed
(00:14:38) nn-: http://tracker.phpbb.com/browse/PHPBB3-10188 says there are notices printed
(00:14:41) nn-: in "some cases"
(00:15:12) naderman: well that seems like it can be solved by replacing the === 1 with a >= 1
(00:15:35) naderman: although so far I haven't managed to get a blank page
(00:15:43) naderman: so I can't even reproduce that problem
(00:16:02) nn-: there is reproduce code there but it is not making much sense
(00:16:07) nn-: and i wrote it :/
(00:16:28) naderman: heh
(00:17:20) nn-: grrrrrrrr
(00:17:26) naderman: I've tried quite a few configurations without any ob_flush now
(00:17:29) naderman: and it seems to work fine
(00:17:41) nn-: btw, our current discussion will be similarly useless should we need to revisit it more than 2 days from now
(00:18:09) naderman: yeah
(00:18:23) naderman: although I do intend to write this down as a proper explanation once we come to any conclusion
(00:21:53) naderman: ah here we go content encoding error
(00:22:11) naderman: output_buffering = 4096
(00:22:15) naderman: and phpbb gzip enabled
(00:22:37) nn-: why does it happen?
(00:22:46) nn-: do things get flushed too much or not enough?
(00:22:48) naderman: but that's not even fixed by any of the ob_flushes
(00:23:01) naderman: nn-: I get it regardless of the ob_flush
(00:23:29) nn-: which code tree are you getting this on
(00:23:45) naderman: err 3.1
(00:24:21) naderman: doesn't occur in 3.0.8
(00:24:46) naderman: ah wait, sure it does
(00:24:50) naderman: same in 3.0.8
(00:25:07) naderman: with and without flushing
(00:25:21) nn-: browser?
(00:25:25) naderman: firefox
(00:25:31) naderman: well I'll curl it
(00:25:46) nn-: gzip streams can be concatenated but that needs to be supported by the application
(00:26:03) nn-: i'm losing my sanity a little here
(00:26:06) naderman: hmm gunzip can decompress it
(00:26:11) nn-: we need reproduce case for 10188 to ensure it stays fixed
(00:26:12) naderman: lol same here
(00:26:50) naderman: gunzip out.gz
(00:26:50) naderman: gzip: out.gz: not in gzip format
(00:27:12) naderman: I put a 1/0; in the beginning of index.php
(00:27:14) naderman: before any other code
(00:27:18) naderman: without any buffering
(00:27:35) naderman: the output is
(00:27:36) nn-: we can't flush before ob_flush
(00:27:36) naderman: Warning: Division by zero in /home/naderman/projects/phpbb/phpbb3/phpBB/index.php on line 13
(00:27:37) naderman: Call Stack:
(00:27:37) naderman:     0.0006     716192   1. {main}() /home/naderman/projects/phpbb/phpbb3/phpBB/index.php:0
(00:27:45) naderman: followed by gzip compressed stuff
(00:28:03) naderman: so one bug is that we do ob_start('ob_gzhandler') even when headers_sent() is true
(00:28:04) nn-: which would be consistent with flushing
(00:28:22) naderman: this is with output buffering
(00:28:23) nn-: so the issue in 10188 is flush being called when ob is active
(00:28:26) naderman: so it's independent of the flushing
(00:28:34) nn-: that can't be done, either do nothing or call ob_flush to send through ob handler
(00:28:39) naderman: I don't think it's what 10188 describes at all
(00:29:08) nn-: i'm guessing this is what my reproduce code tries to demonstrate
(00:29:10) naderman: nn-: sure we can just disable phpbb compression for that request if headers are sent before ob_start is called within phpbb
(00:29:21) nn-: but you're right, title/description seem different
(00:29:36) naderman: we already do that
(00:29:36) naderman: wtf
(00:29:38) naderman: 		if (@extension_loaded('zlib') && !headers_sent())
(00:29:38) naderman: 		{
(00:29:38) naderman: 			ob_start('ob_gzhandler');
(00:29:43) naderman: that's our current code
(00:29:59) naderman: ohh
(00:30:07) naderman: but because of output buffering headers are not sent yet
(00:30:13) naderman: but output has already been generated
(00:30:15) naderman: lol this is just great
(00:30:20) nn-: this seems awfully familiar
(00:30:28) nn-: if write this up i'll buy you a beer 
(00:30:47) naderman: so we need to check ob_get_length there too
(00:31:03) nn-: or ob_get_level which is how the current version of fix came into existence
(00:31:38) naderman: yup that fixes my problem
(00:31:59) naderman: nn-: well ob_get_level has the disadvantage that it triggers on an empty buffer too
(00:32:13) naderman: ob_get_length has the disadvantage that it only looks at one buffer
(00:32:30) nn-: seems sensible
(00:32:38) naderman: I changed page_header to use
(00:32:40) naderman: if (@extension_loaded('zlib') && !headers_sent() && ob_get_level() <= 1 && ob_get_length() == 0)
(00:32:46) nn-: link to line #?
(00:32:53) nn-: if you have it handy
(00:33:01) naderman: 4261 in 3.0.8
(00:34:02) naderman: anyway it still works fine without any flushing in the msg_handler at all
(00:34:04) nn-: this is in msghandler?
(00:35:39) naderman: no
(00:35:46) naderman: the line I changed is in page_header
(00:36:05) naderman: so that it doesn't ever start gzip if output was already generated before that line
(00:36:46) nn-: i'm starting to lose my trains of thought but ob_get_length seems at least as correct as ob_get_level for ob_flush purposes since ob_flush flushes the lowest level only
(00:37:05) nn-: and possibly more correct depending on what ob_flush tries to achieve
(00:37:14) naderman: right now I am only talking about ob_start()
(00:37:29) naderman: I still think we can get rid of ob_flush altogether
(00:38:15) naderman: nn-: any idea how to reproduce 10188?
(00:38:26) naderman: basically while testing this I found a separate other bug ...
(00:39:01) nn-: page_header is a whole separate beast
(00:39:18) nn-: you added ob checks there
(00:39:30) Noxwizard left the room (quit: Quit: Noxwizard signing out).
(00:39:34) naderman: yes
(00:39:45) nn-: so if someone has output buffering enabled you are effectively not going to gzip anything
(00:39:57) naderman: yes I still will
(00:39:58) nn-: or not
(00:39:59) naderman: <= 1
(00:40:03) naderman: so for output buffering I will
(00:40:10) nn-: if someone has more than one level of output buffering
(00:40:12) naderman: as long as nothing was output before we get to page_headr
(00:40:14) naderman: yes
(00:40:15) nn-: this feels hacky
(00:40:18) naderman: and I think that makes sense
(00:40:49) nn-: what does this achieve again?
(00:42:31) nn-: as far as deleting flushes we have to make sure we don't flush when ob is active
(00:42:42) nn-: looks like we only have a few flush calls in the main code
(00:42:44) nn-: a bunch in develop
(00:46:02) naderman: output_buffering > 0, phpbb gzip
(00:46:02) naderman:   error occurs before page_header
(00:46:02) naderman:     -> error is output into buffer
(00:46:02) naderman:     -> then phpbb starts gzip with ob_start('ob_gzhandler')
(00:46:02) naderman:   => page with plaintext content followed by gzip compressed content
(00:46:03) naderman:     -> decompression error
(00:46:27) naderman: that no longer happens with my change to page_header
(00:46:50) naderman: nn-: did you find any way to reproduce 10188?
(00:46:54) naderman: cause I can't
(00:47:04) nn-: uhh give me time
(00:47:07) naderman: heh sure
(00:47:33) nn-: can't do it while following what you are doing here at the same time
(00:47:43) rxu: hmm
(00:47:49) nn-: ohai rxu
(00:47:54) naderman: rxu: hey, you reported it :D
(00:48:00) rxu: hey nn- :))
(00:48:01) naderman: rxu: how did you manage to get a blank page?
(00:48:05) rxu: yeah :P
(00:48:18) rxu: regrettably that wasn't me
(00:48:31) ***nn- breathes relief, now rxu can undergo brain mushing
(00:48:40) rxu: it was reported on our russian IST board, nn- has read it
(00:48:49) nn-: link again please
(00:48:54) rxu: sec
(00:48:55) nn-: and it should go in the ticket
(00:48:59) naderman: indeed
(00:49:15) rxu: I just got a thing from the manual
(00:49:24) rxu: flush() may not be able to override the buffering scheme of your web server and it has no effect on any client-side buffering in the browser. It also doesn't affect PHP's userspace output buffering mechanism. This means you will have to call both ob_flush() and flush() to flush the ob output buffers if you are using those.
(00:49:54) nn-: naderman: your above scenario is nn-approved
(00:50:22) nn-: but what about manual ob_start
(00:51:09) naderman: rxu: the problem is that we think flushing should not be necessary at all
(00:51:15) naderman: the only reason to keep is, is your report
(00:51:19) naderman: but we cannot reproduce your report
(00:52:01) nn-: naderman: if you delete ob level check i would approve
(00:52:19) naderman: nn-: but if I remove it the length check is broken
(00:52:19) nn-: people can't ob-wrap phpbb with gzip on since it sets headers
(00:52:24) nn-: why?
(00:52:31) naderman: I cannot check the length for multiple ob levels at a time
(00:52:39) naderman: so I can't make sure that no output was generated before phpbb
(00:52:43) nn-: what i'm saying is only check nearest level
(00:52:50) naderman: but why?
(00:53:00) naderman: it makes sense to me that we only enable gzip if we are at the top level?
(00:53:14) nn-: yes, in which case there is only one level
(00:53:14) naderman: oh wait
(00:53:15) naderman: now I get it
(00:53:18) rxu: naderman : calling flush() after ob_flush() sends buffer to the browser regardless?
(00:53:21) naderman: you are saying it's broken then anyway
(00:53:27) nn-: pretty much
(00:53:35) rxu: nn- : http://www.phpbbguru.net/community/topic16064-420.html#p326091 <-- starting point
(00:53:36) naderman: rxu: what? I don't understand
(00:53:40) nn-: it's not a reliable check
(00:53:57) nn-: ob_get_length makes sense, ob_get_level not so much
(00:53:57) naderman: well but it makes it less likely to break
(00:54:09) naderman: because you can't disable phpbb's gzip if the page doesn't render
(00:54:24) naderman: there is no way you want to use gzip if ob_get_level is > 1
(00:54:32) naderman: however you might have accidently enabled it
(00:54:33) nn-: that's true i suppose
(00:54:44) nn-: so we don't support wrapping phpbb into ob
(00:54:44) naderman: so I'd rather skip the ob_start in that case too
(00:54:51) naderman: no we do
(00:54:55) naderman: but not with gzip
(00:54:56) nn-: with gzip
(00:54:59) naderman: yes
(00:55:03) nn-: so if we disable gzip we don't really lose much
(00:55:12) naderman: whoever wraps phpbb can easily gzip it themselves
(00:55:21) naderman: so there's really no point for us to support that
(00:55:24) nn-: ok i think i approve completely now
(00:55:28) naderman: k cool
(00:55:32) naderman: I'll create a new ticket for that one
(00:55:33) nn-: the page header thing
(00:55:54) naderman: now we just need to figure out why we ever need to flush
(00:56:32) rxu: output buffer enabled -> notice generated and stored in buffer -> no flush is no content
(00:56:36) nn-: we need a ticket for email not correctly collecting errors
(00:56:59) nn-: i suggest making a new one and later maybe just closing 10225 if it ends up having no code
(00:57:08) naderman: rxu: no, there is content, it is just not decompressable
(00:57:16) naderman: the content is always flushed on exit
(00:57:20) rxu: naderman : yes, if gzipped
(00:57:30) naderman: otherwise the content is just sent
(00:57:34) naderman: and there
(00:57:50) naderman: the buffer is always flushed automatically by exit;
(00:57:52) rxu: naderman : what code was added earlier: msg_handler flush or exit_handler flush?
(00:58:02) naderman: rxu: I have no idea, why?
(00:58:21) rxu: I just wondered why both is needed
(00:58:29) rxu: are*
(00:58:31) naderman: rxu: they are very different
(00:58:38) naderman: one is for outputting content before the error message
(00:58:43) naderman: one is for outputting anything at all
(00:58:47) rxu: k
(00:58:58) naderman: I don't know why anybody would want to output content before the error message however
(00:59:06) naderman: the one in exit_handler makes sure it's always output
(00:59:12) rxu: naderman : then we probably should call echo before we flush it
(00:59:15) naderman: nn-: will you create the ticket for email/error handler?
(00:59:21) naderman: rxu: what?
(00:59:27) naderman: echo of what?
(00:59:32) naderman: and why would we flush anything at all?
(00:59:39) nn-: ok
(00:59:41) rxu: echo of notice
(00:59:48) naderman: rxu: well we echo it either way
(00:59:56) naderman: rxu: why does there need to be a flush inside of that function?
(01:00:02) naderman: there is a flush in exit_handler
(01:00:04) naderman: that should be enough
(01:00:31) naderman: rxu: what I really need is to see a page with no content because an error occured
(01:00:38) naderman: because right now I don't believe that ever happens
(01:01:16) naderman: based on what I've seen it doesn't look like the bug in http://tracker.phpbb.com/browse/PHPBB3-10188 exists at all
(01:01:26) rxu: naderman : it happened for users with 3.0.8
(01:01:31) naderman: rxu: which users
(01:01:36) naderman: what settings did they have
(01:01:37) rxu: nn- : ?
(01:01:41) naderman: which version of PHP?
(01:01:48) naderman: how can that possibly happen for them but not for me?
(01:01:55) nn-: reading ist topic
(01:01:56) naderman: I use output_buffering=4096
(01:02:01) naderman: and I have E_NOTICE/E_WARNING errors
(01:02:05) naderman: but I never get a blank page
(01:02:17) nn-: the bug was broken compressed output with output buffering at 4096
(01:02:24) rxu: naderman : wait while nn- reads the topic in russian :)
(01:02:31) naderman: rxu: well that I have fixed with the page_header
(01:02:35) naderman: err
(01:02:36) nn-: and notice? error messages getting printed
(01:02:45) naderman: nn-: that I have fixed with the page_header
(01:02:55) naderman: the broken compression I mean
(01:03:06) naderman: so basically we can delete that entire flushing code
(01:03:18) nn-: if flush fixes it the problem might be elsewhere
(01:03:20) DavidIQ left the room (quit: Quit: To infinity...and beyond!).
(01:03:29) nn-: unless msg handler is called before page start?
(01:03:36) naderman: I tried that
(01:03:38) rxu: I think so
(01:03:39) naderman: works fine for me
(01:03:43) naderman: after the page_header fix anyway
(01:05:22) nn-: is it possible for msg_handler to be called before page_start?
(01:05:28) naderman: yes
(01:05:41) naderman: basically anywhere after the inclusion of common.php
(01:05:47) naderman: and the call to page_start
(01:05:54) naderman: so most of PHP code is executed in that scope
(01:05:57) naderman: err
(01:06:00) rxu: just put 1/0; before page_header() call :)
(01:06:00) naderman: most of phpBB's code
(01:06:05) naderman: rxu: yup I did
(01:06:07) naderman: works fine for me
(01:06:15) naderman: well gave me broken compression
(01:06:22) naderman: but not no content
(01:06:27) nn-: trying to understand why the fix fixed reported issue
(01:06:30) naderman: and the flush didn't fix it either
(01:06:42) naderman: nn-: I don't understand that either
(01:06:50) nn-: i love it when this happens
(01:07:27) nn-: rxu: was your fix the same as  http://www.phpbbguru.net/community/topic16064-420.html#p326104 ?
(01:08:01) nn-: so i mean this should be simple to reproduce
(01:08:29) nn-: install 3.0.8, set output buffering to 4096 and maybe enable phpbb gzip and add 1/0 somewhere
(01:08:58) naderman: oh now I get it
(01:09:02) naderman: I get the broken compression
(01:09:15) naderman: (rxu: broken compression != no content)
(01:09:58) naderman: rxu: I use 3.0.8
(01:10:23) naderman: I put 1/0;  before page_header( in index.php
(01:10:24) nn-:  This causes page can't be displayed on E_NOTICE or E_WARNING in some cases.
(01:10:28) nn-: technically that's accurate
(01:10:31) naderman: I get broken compression
(01:10:35) nn-: but broken compression fact was omitted
(01:10:54) naderman: yeah which was kind of key to this whole thing
(01:11:08) nn-: i had it in my reproduce code :P
(01:11:25) naderman: yeah that was very comprehensible :P
(01:11:29) nn-: yay me
(01:11:41) naderman: ok anyway I think my solution to this is: my page_header fix + removal of all flushing in msg_handler
(01:12:08) naderman: nn-: do you agree?
(01:12:14) nn-: wait
(01:12:20) naderman: heh k
(01:12:22) nn-: do you understand why the fix for 10188 fixed it?
(01:12:27) naderman: yes
(01:12:29) nn-: either my fix or http://www.phpbbguru.net/community/topic16064-420.html#p326104
(01:12:34) nn-: why
(01:12:44) rxu: lol
(01:12:46) rxu: [phpBB Debug] PHP Notice: in file /index.php on line 107: Division by zero
(01:12:46) rxu: [phpBB Debug] PHP Notice: in file /includes/functions.php on line 4272: ob_start(): output handler 'ob_gzhandler' cannot be used twice
(01:13:08) rxu: where did I mess the code
(01:13:11) nn-: do you have it enabled in php.ini?
(01:13:20) nn-: and separately, do we check for that?
(01:13:28) rxu: nn- : 4096
(01:13:32) naderman: nn-: the ob_flush() sends headers
(01:13:34) rxu: gzip enabled
(01:13:41) nn-: do you have ob_gzhandler enabled in both php.ini and phpbb
(01:13:42) naderman: nn-: page_header checks headers_sent()
(01:13:57) naderman: nn-: so with the ob_flush in msg_handler gzip compression is never enabled
(01:14:15) naderman: however for errors before msg_handler exists it still fails the same way as before
(01:14:19) naderman: so it's only half a fix ;-)
(01:14:33) nn-: i meant
(01:14:42) nn-: rxu: do you have ob_gzhandler enabled in php.ini and gzip compression enabled in phpbb
(01:14:49) nn-: naderman: do we check for this situation and refuse to compress again
(01:14:56) rxu: nn- : let me check
(01:15:08) naderman: nn-: current code in page_header is
(01:15:12) naderman: 		if (@extension_loaded('zlib') && !headers_sent())
(01:15:13) naderman: 		{
(01:15:13) naderman: 			ob_start('ob_gzhandler');
(01:15:19) rxu: nn- : yes, I'll disable php.ini part now
(01:15:26) naderman: nn-: so gzip compression is only started when headers are not sent yet
(01:15:30) nn-: naderman: not sure i see how that helps
(01:15:38) naderman: when you ob_flush() in msg_handler
(01:15:38) nn-: headers are sent when output handler runs at the end
(01:15:50) nn-: well we're talking about deleting flushes
(01:15:53) naderman: then headers are sent inside of the msf_handler
(01:15:53) nn-: so this will break
(01:16:02) naderman: beforge page_header
(01:16:13) naderman: nn-: no it is fixed by my page_header fix
(01:16:18) naderman: because the error will still be output
(01:16:27) naderman: so my ob_get_length() check will prevent it from starting gzip
(01:16:29) nn-: uhh
(01:16:29) rxu: nn- : naderman just reproduced 10188
(01:16:36) rxu: no output in IE
(01:16:45) rxu: 3.0.8
(01:16:46) naderman: oh ok IE just silently fails?
(01:16:51) naderman: that sucks
(01:16:52) naderman: :)
(01:16:53) rxu: yup
(01:16:58) naderman: nn-: understand my solution?
(01:17:00) rxu: probably FF as well
(01:17:10) nn-: really we should call it "white page in ie" since "no output" means different things to us developers
(01:17:14) nn-: naderman: not quite
(01:17:25) naderman: rxu: no, firefox gives you a proper error message
(01:17:29) nn-: php.ini gzhandler enables output buffering
(01:17:33) nn-: but it does not send headers i don't think
(01:17:36) rxu: nn- : for Opera there's kinda no output as well
(01:17:42) naderman: nn-: it does if you call ob_flush();
(01:17:54) nn-: naderman: ok, but if we are deleting flush we need a different check
(01:17:57) rxu: just error and a garbage
(01:18:04) naderman: nn-: yes, the one that I told you about already
(01:18:06) naderman: for page_header
(01:18:10) naderman: the one with ob_get_length()
(01:18:15) nn-: that check i don't see how it works
(01:18:22) naderman: see the problem right now is
(01:18:25) nn-: becase there is no output at that point normally
(01:18:26) naderman: an error occurs before page_header
(01:18:28) rxu: nn- [phpBB Debug] PHP Notice: in file /index.php on line 107: Division by zero
(01:18:28) rxu: �
(01:18:31) rxu: and so on
(01:18:37) naderman: break please
(01:18:45) rxu: naderman : k :)
(01:20:33) naderman: output buffering is enabled
(01:20:34) naderman:   3.0.8:
(01:20:34) naderman:   1. msg_handler is set as error handler
(01:20:34) naderman:   2. error occurs
(01:20:34) naderman:   3. msg_handler outputs error message
(01:20:35) naderman:     -> output is buffered, nothing sent to browser
(01:20:37) naderman:   4. page_header is started
(01:20:39) naderman:     -> ob_start('ob_gzhandler')
(01:20:42) naderman:     -> gzip header
(01:20:44) naderman:   5. more output, going through ob_gzhandler
(01:20:46) naderman:   6. exit
(01:20:48) naderman:     -> broken compression
(01:20:55) naderman: nn-: now your fix changes step 3
(01:22:35) naderman:   nn-'s fix
(01:22:35) naderman:   1. msg_handler is set as error handler
(01:22:35) naderman:   2. error occurs
(01:22:35) naderman:   3. msg_handler calls ob_flush()
(01:22:35) naderman:     -> headers are sent
(01:22:36) naderman:     -> outputs error message
(01:22:38) naderman:     -> output is buffered, not sent to browser
(01:22:40) naderman:   4. page_header is started
(01:22:43) naderman:     -> headers_sent() is true
(01:22:45) naderman:       => no gzip ob_start
(01:22:47) naderman:       => no gzip header
(01:22:49) naderman:   5. more output
(01:22:51) naderman:   6. exit
(01:22:54) naderman:     -> plaintext
(01:23:20) naderman:   naderman's fix
(01:23:21) naderman:   1. msg_handler is set as error handler
(01:23:21) naderman:   2. error occurs
(01:23:21) naderman:   3. msg_handler outputs error message
(01:23:22) naderman:     -> output is buffered, nothing sent to browser
(01:23:24) naderman:   4. page_header is started
(01:23:27) naderman:     -> ob_get_length() > 0
(01:23:29) naderman:       => no gzip ob_start
(01:23:31) naderman:       => no gzip header
(01:23:33) naderman:   5. more output
(01:23:35) naderman:   6. exit
(01:23:38) naderman:     -> plaintext
(01:23:40) naderman: ok
(01:23:44) naderman: now please ask questions ^_^
(01:23:49) naderman: nn-: does this make sense?
(01:24:35) naderman: the added advantage of my solution is that it also deals with errors that happen before the msg_handler is even the error handler
(01:25:04) naderman: in that case your ob_flush solution would still result in broken compression, because msg_handler is never called, but page_header starts compression
(01:25:47) naderman: in my case the pre-msg_handler output results in an ob_get_length() > 0 so I don't start gzip
(01:28:21) nn-: agree
(01:28:32) Marshalrusty: Whoa
(01:28:44) nn-: so we use your fix and delete ob_flush from msg handler
(01:28:48) naderman: yup
(01:28:57) nn-: now, msg handler has two ob_flush calls
(01:29:00) nn-: what about the second one
(01:29:10) naderman: that one is just as unecessary
(01:29:10) nn-: http://tracker.phpbb.com/browse/PHPBB3-10188 rev1
(01:29:26) nn-: feel free to shorten the title
(01:29:39) naderman: or rather that is the most pointless one ever
(01:29:45) naderman: it checks if !ob_get_level()
(01:29:52) naderman: and then ob_flush()es
(01:29:57) naderman: that never made any sense at all
(01:30:44) naderman: alright I'll take care of this
(01:30:44) nn-: blame on that lists different commits for every line
(01:31:03) nn-:                2007-08-13               Some changes... non-invasive...              
(01:31:10) nn-: :) the gift that keeps on giving
(01:31:14) naderman: heh
(01:31:19) rxu: :)
(01:32:50) naderman: I'll be gone for a bit
(01:32:55) naderman: going to finish this up tonight
(01:33:06) naderman: so Andreas can prepare rc3 tomorrow
(01:34:06) rxu: Marshalrusty : long reading? :))
(01:35:01) Marshalrusty: rxu: I started to read, but then I realized that it's easier to hit myslf in the head with an axe
(01:35:14) rxu: lol
(01:36:24) nn-: this second flush seems like voodoo programming
(01:36:40) rxu: nn- : exit_handler?
(01:36:47) nn-: no in msg handler
(01:36:50) nn-: second ob_flush
(01:36:50) rxu: ah
(01:37:00) nn-: i can post commit links if anyone wants to see them
(01:37:14) nn-: it was neutered at one point with the ob level check
(01:37:41) rxu: looks like hacks to workaround bugs
(01:37:51) nn-: i suppose the entire history of that flushing was essentially a hunt for the cause that we have been discussing just now
(01:38:13) rxu: yep looks like it
(01:38:21) nn-: so delete it and see what happens
(01:39:32) nn-: now to update some tickets
(01:39:55) nn-: also, https://github.com/phpbb/phpbb3/commit/ab8177a0338c0d9746d87d97c5b3d9c9b7086aef
(01:40:06) nn-: looks like it might cause problems somewhere
(01:40:08) rxu: nn-  : reopen 10188 :)
(01:40:10) nn-: assuming that code still exists
(01:40:55) nn-: well we have a few tickets which are related
(01:40:59) rxu: it has been changed several times already
(01:41:06) nn-: 10225 is kind of messy also
(01:41:49) rxu: hopefully we have sorted out that flushing thing finally
(01:42:06) nn-: feel like reviewing the other *flush calls? :)
(01:42:13) rxu: the cause of issue at least
(01:42:38) rxu: nn- : want me to kill myself? :))
(01:42:40) nn-: e.g. does cron flush to ob?
(01:43:22) nn-: i'm going to file a ticket for this
(01:43:25) nn-: just because
(01:43:32) rxu: OMG
(01:43:46) rxu: flush() was found in 7 files
(01:43:53) rxu: *flush()*
(01:44:44) rxu: including cron.php
(01:44:56) nn-: really? :P
(01:45:09) rxu: oh it's commented out :)
(01:45:17) nn-: not in head
(01:45:31) nn-: and maybe that should be backported
(01:46:26) rxu: file.php has 2 flush()es
(01:47:13) rxu: nn- : backported from page_header?
(01:48:17) nn-: the uncommenting of flush that happened as part of 3.1 cron should probably be backported to 3.0
(01:48:41) rxu: ah that thing
(01:51:17) nn-: http://tracker.phpbb.com/browse/PHPBB3-10244
(01:52:13) nn-: we target everything to 3.0.10 now right, i'm going to mark this for 3.0.10
(01:53:02) rxu: ob_flash - typo
(01:57:05) rxu: nn- : well, does it all mean that a single ob_flush() call in exit_handler makes no sense?
(01:57:53) rxu: it's called once regardless of the buffer deep
(01:58:02) nn-: you can't just throw such questions 
(01:58:36) nn-: i mean i have to look at it and figure this out
(01:58:54) rxu: sure, just discussing :)
(01:58:54) nn-: i'm not saying anything is necessarily wrong, but it may be the case that wrong behavior exists but is unnoticed, e.g. cron
(01:59:09) nn-: i think i'm going on 4 hours looking at flushing
(02:02:09) rxu: while (@ob_end_flush()); looks nice
(02:02:28) nn-: sounds like something one might find in php manual comments
(02:02:42) rxu: that's not from comments
(02:02:51) nn-: php manual itself?
(02:02:53) rxu: but from official manual example ;)
(02:02:54) nn-: O_o
(02:02:58) rxu: yup
(02:04:16) The account has disconnected and you are no longer in this chat. You will be automatically rejoined in the chat when the account reconnects.
(02:04:35) The topic for #phpBB-dev is: phpBB Development Discussion - please use #phpbb for support and #phpbb-coding for MOD/Styles development | Rhea (v4) discussion: http://bit.ly/89MkFg | Note: All chat is being logged
(02:04:38) mode (+o nn-) by ChanServ
(02:11:04) nn-: http://tracker.phpbb.com/browse/PHPBB3-10245 - blocker?
(02:16:42) nn-: http://tracker.phpbb.com/browse/PHPBB3-10191
(02:17:09) nn-: the fix looks as legit as the preexisting comment in the code above it
(02:19:32) nn-: now for the actual fix
(02:19:40) nn-: that naderman is going to commit
(02:19:50) nn-: we can start a new ticket for it and make 10225 and 10188 duplicates of it
(02:20:02) nn-: benefit being the new ticket will have higher signal to noise ratio
(02:20:18) rxu: I wonder if ob_flush() is correct if called alone
(02:20:26) nn-: or we can reopen 10188 and re-fix 10188 or fix 10225
(02:20:32) nn-: 10225 is confusing as it refers to timezones
(02:20:37) rxu: as per the manual, it is to be called along with the flush()
(02:20:45) nn-: you can call ob_flush by itself
(02:20:50) nn-: it flushes one level of output buffering
(02:21:11) rxu: but not the topmost level
(02:21:19) nn-: that's right
(02:21:32) rxu: thus a blank page could arise
(02:21:38) nn-: it should not
(02:21:54) nn-: first of all the flush in exit handler has no reproduce case justifying it
(02:22:12) nn-: my test with not closing output buffering resulted in output getting sent anyway
(02:22:23) nn-: phpbb should close all output buffers
(02:22:52) nn-: actually
(02:22:57) nn-: i think we don't in case of gzip
(02:23:02) nn-: we just do ob_start(ob_gzhandler)
(02:23:03) nn-: so meh
(02:24:46) rxu: phpbb doesn't count buffer levels even. That's probably why "...some setups display a blank page if the flush() is not there."
(02:24:48) rxu: ?
(02:25:16) rxu: but it sounds like guassing though, who knows
(02:25:22) rxu: guessing*
(02:26:32) rxu: anyway, it all seems too much for RC phase
(02:27:05) rxu: what about reverting 10188 fix back and making global buffer thing cleanup for 3.0.10?
(02:27:23) nn-: not a great idea in my opinion
(02:27:31) nn-: especially naderman's fix covers more 
(02:27:47) nn-: 10188 will be "reverted" by virtue of that code going away entirely
(02:28:07) nn-: it would be nice to get more testing for it but we can just extend rc3 a bit
(02:35:41) naderman: yeah I think we'll wait a week or so till final
(02:41:44) nx-: https://github.com/phpbb/phpbb3/pull/239 - why did this break? anyone know?
(02:43:39) rxu: nx- : http://www.phpbb.com/community/viewtopic.php?p=13010553#p13010553
(02:43:55) rxu: oh sorry, private link :/
(02:44:27) nx-: exactly, i have to reach for my other keyboard to see it
(02:45:13) nx-: if it has useful information it needs to go into the ticket though
(02:45:25) nx-: basically same situation as what we just had with flushing
(02:45:44) nx-: these ui changes are a complete mystery to me
(02:46:12) nx-: probably to every board admin who is not a frontend developer should they need to look at them for whatever reason
(02:48:24) JoshyPHP [~JoshyPHP@85.69.182.23] entered the room.
(02:49:02) rxu: nx- : agreed
(02:52:33) nx-: check this out
(02:54:05) nx-: http://trashb.info/7b98445e
(03:03:30) rxu: nx- : what's the case for level of 11?
(03:04:04) nx-: it is actually two ones
(03:04:16) rxu: I mean, what code causes that
(03:04:31) nx-: in cli php ignores output buffering setting in php.ini
(03:14:00) rxu: nx- : yes, that is what php manual says :P
(03:16:04) rxu: but it also says you still can use output_buffering functions with cli
(03:16:18) nx-: integration testing phpbb from command line seems a little impossible
(03:16:33) nx-: well i'm trying to test behavior with output buffering and gzip configured in php.ini
(03:16:44) rxu: yeah I see
(03:18:13) rxu: it looks like only ob_start can be used to manipulate output with cli
(03:18:25) rxu: and related functions
(03:19:26) nx-: i'm not really seeing unit testing working here
(03:21:41) rxu_ [~Miranda@FTTB-dynamic-79.104.202.23.ranetka.ru] entered the room.
(03:22:19) nickvergessen [~nickv@phpbb/developer/nickvergessen] entered the room.
(03:22:19) mode (+o nickvergessen) by ChanServ
(03:22:21) rxu left the room (quit: Disconnected by services).
(03:22:23) nx-: it should not be impossible to load our initial schema into a designated db, right
(03:22:28) rxu_ left the room (quit: Client Quit).
(03:22:55) rxu [~Miranda@phpbb/developer/rxu] entered the room.
(03:22:55) mode (+o rxu) by ChanServ
(03:24:09) rxu: inet fails heh
(03:24:17) nx-: it should not be impossible to load our initial schema into a designated db, right
(03:24:42) nx-: might need some test-only data for admin login/password and such
(03:26:30) nx-: 1. create sqlite database 2. load schema 3. load data 4. load test data (admin account, etc.) 5. start apache given a) apache config, b) php ini 6. issue requests against apache - with - curl?
(03:27:01) nx-: i suppose php has an http client we can use
(03:52:26) rxu: nx- : "The PHP CLI doesn't not support GET, POST or file uploads."
(03:52:59) nx-: i wonder how people managed to write a php webserver
(03:55:14) marc1706 [~Marc@phpbb/modifications/marc1706] entered the room.
(03:55:14) mode (+o marc1706) by ChanServ
(03:55:49) naderman: nx-: well you implement HTTP yourself
(03:55:54) naderman: all you need is sockets
(03:56:28) nx-: i guess
(03:57:05) rxu: nx- : probably based on PHP with curl as well
(03:58:11) nx-: redis comes with no man pages, excellent
(03:59:39) marc17061 [~Marc@p4FC60B60.dip0.t-ipconnect.de] entered the room.
(04:01:10) marc17061 left the room (quit: Client Quit).
(04:01:34) marc17061 [~Marc@marc1706.heim11a.tu-clausthal.de] entered the room.
(04:01:38) marc1706 left the room (quit: Ping timeout: 240 seconds).
(04:02:15) marc17061 left the room (quit: Client Quit).
(04:02:35) marc1706 [~Marc@phpbb/modifications/marc1706] entered the room.
(04:02:35) mode (+o marc1706) by ChanServ
(04:23:53) tumba25 [~tumba25@phpbb/modifications/tumba25] entered the room.
(04:23:54) mode (+o tumba25) by ChanServ
(04:30:40) nx-: http://www.thewhir.com/web-hosting-news/062411_Web_Host_Go_Daddy_Rumored_to_Sell_for_2_Billion
(04:39:35) naderman: nx-: hmm should http://tracker.phpbb.com/browse/PHPBB3-10245 even still go into 3.0.9?
(04:39:48) naderman: it seems like that is an optional improvement now that we should rather make in 3.0.10?
(04:40:19) nx-: i won't be heart-broken if it does not
(04:41:02) nx-: maybe it should not since it is a behavior change
(04:41:16) nx-: and error collector is pretty new
(04:41:17) naderman: yeah
(04:41:25) naderman: I'll move it to 3.0.10
(04:41:37) nx-: sounds good

part 8

(09:27:32) bantu: okay, just read the backlog
(09:27:34) bantu: nice work
(09:28:23) bantu: naderman, nx-, nn-: has anyone of you verified that the flush call in exit_handler() is correct?
(09:41:37) bantu: I think http://tracker.phpbb.com/browse/PHPBB3-10191 should be closed as 3.0.9-RC1
(09:41:42) bantu: since it was merged
(09:41:47) bantu: maybe create a new ticket
(09:42:17) bantu: and please review whether https://github.com/phpbb/phpbb3/pull/198/files was correct
(09:42:43) bantu: I'll be back in 2 or 3 hours.
(09:55:38) rxu: bantu : there's another ticket on flush calls http://tracker.phpbb.com/browse/PHPBB3-10244
(09:56:51) bantu: rxu: yes, but http://tracker.phpbb.com/browse/PHPBB3-10191 was already merged and thus could introduce regression while http://tracker.phpbb.com/browse/PHPBB3-10244 is irrelevant for 3.0.9
(10:00:13) rxu: yes it is for 3.0.10. 10191 actually should go to 3.0.9 as it's been merged. Regarding exit_handler flush calls I guess it should be revisited later along with 10244
(10:00:54) bantu: I don't want this changed twice, once in 3.0.9 and once in 3.0.10
(10:01:24) bantu: so either it is okay according to the new informations we have and can stay in 3.0.9
(10:01:32) bantu: or it should be reverted and can be revisited for 3.0.10
(10:01:59) rxu: we have also http://tracker.phpbb.com/browse/PHPBB3-10245 flush related
(10:02:52) bantu: rxu: yes but we no longer need this in 3.0.9 because we've removed the flush calls from msg_handler()
(10:03:23) bantu: but using the error collector is still the better way to do it
(10:03:41) rxu: agreed
(10:03:48) bantu: great
(10:03:53) rxu: :)
(10:06:04) bantu: okay but now I'm gone for real
(10:06:11) nickvergessen: have fun
(10:06:12) nickvergessen: :P
(10:07:56) bantu: rxu: wait, you're right. let's just take http://tracker.phpbb.com/browse/PHPBB3-10191 for 3.0.9-RC1 and then we cann still use http://tracker.phpbb.com/browse/PHPBB3-10244 for 3.0.10
(10:14:00) DavidIQ|iPad left the room (quit: Changing host).
(10:14:00) DavidIQ|iPad [~iqpad@phpbb/manager/DavidIQ] entered the room.
(10:14:04) DavidIQ|iPad left the room.
(10:14:14) DavidIQ|iPad [~iqpad@phpbb/manager/DavidIQ] entered the room.
(10:14:14) mode (+o DavidIQ|iPad) by ChanServ
(11:23:07) nickvergessen left the room (quit: Quit: Leaving.).
(11:32:12) naderman: re
(11:33:51) naderman: bantu: yeah 10191 should be fine
(11:40:52) amator [~amator@213.169.88.84] entered the room.
(11:41:27) amator left the room.
(11:41:31) amator [~amator@213.169.88.84] entered the room.
(11:41:42) amator left the room.
(11:41:47) amator [~amator@213.169.88.84] entered the room.
(11:41:58) amator: Hi, everyone!
(11:42:36) rxu: hi amator
(11:42:48) amator: Hi) I know your from phpbbguru
(11:43:00) rxu: same here ;)
(11:43:31) naderman: so hmm what's left for 3.0.9
(11:43:49) rxu: everything looks cleaned up
(11:44:03) naderman: 2 unmerged fixes
(11:44:06) naderman: but that's it
(11:44:06) naderman: yup
(11:44:25) naderman: guess we'll wait for andreas to return and merge them
(11:44:28) naderman: and then release rc3