Would anyone object to releasing 8.0 from 8.0.38?
Sounds good to me.
I don't think I have any known major issues left to fix.
On 02/27/15 19:15, 10353@lyskom.lysator.liu.se wrote:
Would anyone object to releasing 8.0 from 8.0.38?
Sounds good to me.
I don't think I have any known major issues left to fix.
Stdio.File buffer mode does not really work. Maybe we can fix that first? And can we get setsockopts (nodelay, etc) into this release, too? sorry for the repost.
arne
Stdio.File buffer mode does not really work. Maybe we can fix that first?
It works very well, but perhaps not for what you want. Someone else has to answer if your uses are intended and buggy or a feature requests.
And can we get setsockopts (nodelay, etc) into this release, too? sorry for the repost.
I like setsockopts, but I don't want feature creep. Put it in 8.1.
On Fri, 27 Feb 2015, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
Stdio.File buffer mode does not really work. Maybe we can fix that first?
It works very well, but perhaps not for what you want. Someone else has to answer if your uses are intended and buggy or a feature requests.
Yes, alright. Sorry for the oversimplification. But I currently have two problems, which I think are bugs:
1) When adding data the first time after set_buffer_mode to the out buffer, the first 100 bytes are reappended at the end of the buffer.
2) The close callback is not triggered, instead the read event loops with no new data in the in buffer.
I will add testcases.
And can we get setsockopts (nodelay, etc) into this release, too? sorry for the repost.
I like setsockopts, but I don't want feature creep. Put it in 8.1.
Ok, will merge those commits into 8.1 and backport after the first 8.0 release, then.
Otherwise, I am all for a 8.0 release.
There is one other SSL bug in pike 8. This happens very predictably when connecting to a roxen+pike8 with chromium. The problem is that from the close callback the session is removed from the session cache. If the session is in use in another connection, it ends up without master_secret which then leads to an error. Is invalidating the session correct behavior in this case? RFC 4346 in 7.2.1:
Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice.
arne
On 02/28/15 11:18, Arne Goedeke wrote:
On 02/27/15 22:18, Arne Goedeke wrote:
I will add testcases.
I just pushed a buffer mode test to socktest.pike. I also added a SSL test for a bug which I almost forgot about. is_open() hangs in blocking mode.
The set_buffer_mode on Stdio.File objects with Stdio.Buffer objects will write data in the wrong order. We can of course simply disallow such use in 8.0.
It's already there, in socktest.pike.
Stdio.Buffer Socket test using PollDeviceBackend Child: Testing accept Failed to read complete data, errno=0, "Success". 10:Input buffer: 28266 bytes. 10:Expected data: 28266 bytes.
Child failed with errcode 1 Parent: Testing accept Failed to read complete data, errno=0, "Success". 10:Input buffer: 28266 bytes. 10:Expected data: 28266 bytes.
Stdio.Buffer Socket test using PollDeviceBackend in IPv6 mode Child: Testing accept Failed to read complete data, errno=0, "Success". 10:Input buffer: 28266 bytes. 10:Expected data: 28266 bytes.
Child failed with errcode 1 Parent: Testing accept Failed to read complete data, errno=0, "Success". 10:Input buffer: 28266 bytes. 10:Expected data: 28266 bytes.
pike-devel@lists.lysator.liu.se