Ticket #456 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

IBuffer .copy() does not work as expected.

Reported by:	pmfp	Assigned to:	kris
Priority:	normal	Milestone:	0.98 RC 2
Component:	IO	Version:	trunk
Keywords:		Cc:

Description

Using Tango and Mango trunks as of 09May07, connecting an IBuffer and a FileConduit? using the IBuffer's copy does not work as expected.

This does NOT work:

auto output = response.getOutputBuffer();
auto file = new FileConduit("index.html");

output.copy(file); // NOTE THIS LINE
output.flush();

This works:

auto output = response.getOutputBuffer();
auto file = new FileConduit("index.html");

output.conduit.copy(file); // NOTE THIS LINE
output.flush();

Change History

05/09/07 09:28:20 changed by pmfp

priority changed from critical to major.

05/09/07 09:56:52 changed by larsivi

owner changed from sean to kris.
priority changed from major to normal.
component changed from Core Functionality to IO.
milestone set to 0.98 RC 2.

05/09/07 12:53:15 changed by kris

status changed from new to assigned.

This works as expected, where Cout.buffer is just an ordinary buffer:

import tango.io.Console;
import tango.io.FileConduit;

void main()
{
        auto bar = new FileConduit ("existing.file");
        Cout.buffer.copy(bar).flush;
}

Can you confirm? What is it that does not operate?

05/09/07 13:14:34 changed by kris

BTW, if you're using a ServletResponse? (seems like your doing http work?) there is a copyFile() method on it ... that one uses conduit.copy() like your example, but that's only because buffer.copy() is a recent addition

05/09/07 13:46:09 changed by pmfp

The example you provided works.

The specific instance of IBuffer, which does not appear to use any modifications to it, that does not work, is in mango.net.http.server.HttpResponse?. Since there are no modifications to the buffer, I would guess that it is still a tango issue.

The result of the first code snippet in my original post is that it does not pass any data through output (i.e. in this case it does not show anything on the page, while the second example does).

05/10/07 00:48:00 changed by kris

status changed from assigned to closed.
resolution set to fixed.

fixed in [2182], though the issue appears to be more complex than expected. The cause appears to be flushing an empty buffer which, for some reason, is interpreted by the client Browser as the end of input. The client then closes the socket, causing an exception on the server as it tried to write more output.

Tried various combinations of returned headers, but nothing appears to alter the behaviour. To get around it, I made Buffer.fill() more 'optimistic' about the buffer space, such that it does not flush before filling.

Ticket Navigation