New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 19 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Cannot get remaining data after calling GetDocumentStream() in response to SignalHeaderAvailable

Reported by nikolay....@viblast.com, Apr 29 2014 Back to list

Issue description

What steps will reproduce the problem?
1. Call GetDocumentStream() and then call Read on the stream in response to SignalHeaderAvailable

What is the expected result?
To be able to read the data after the headers. Alternatively, I've tried connecting to SignalEvent on DocumentStream, but it doesn't fire with SE_READ, only with SE_CLOSE(after the socket timeouts, the data is available long before that).

What do you see instead?
The assert on line 574 (ASSERT(processed <= len_) ) in httpbase.cc fails.



 
After connecting to SignalHeaderAvailable:
client_.SignalHeaderAvailable.connect(this, &AsyncHttpRequest::OnHeadersHttpReceived);

I'm trying to do:

void AsyncHttpRequest::OnHeadersHttpReceived(talk_base::HttpClient *client,bool final, size_t size) {
	talk_base::StreamInterface *stream = client_.GetDocumentStream();

	talk_base::StreamResult res;

	do{
		char buff[20000];
		size_t read, written;
		int err;


		res = stream->Read(buff, 20000, &read, &err);

		LOG(WARNING) << "RES " << res << " read " << read;
	} while(res == talk_base::SR_SUCCESS );
}

The other way I tried is:

void AsyncHttpRequest::OnHeadersHttpReceived(talk_base::HttpClient *client,bool final, size_t size) {
	talk_base::StreamInterface *stream = client_.GetDocumentStream();
	stream->SignalEvent.connect(this, &AsyncHttpRequest::OnStreamEvent);

void AsyncHttpRequest::OnStreamEvent(talk_base::StreamInterface *stream, int eventType, int errorCode){
	talk_base::StreamResult res;

	do{
		char buff[2000000];
		size_t read, written;
		int err;

		res = stream->Read(buff, 20000, &read, &err);

	} while(res == talk_base::SR_SUCCESS );
}



Project Member

Comment 2 by braveyao@webrtc.org, Apr 30 2014

Cc: braveyao@webrtc.org
Owner: juberti@webrtc.org
@justin, could you please help on this?
Project Member

Comment 3 by juberti@webrtc.org, May 7 2014

Owner: pthatcher@webrtc.org
Status: Assigned (was: NULL)
Project Member

Comment 4 by vikasmarwaha@webrtc.org, Jun 9 2014

Cc: vikasmarwaha@webrtc.org
Labels: Mstone-38

Comment 5 by vrk@webrtc.org, Oct 14 2014

Labels: Area-PeerConnection
Project Member

Comment 6 by pthatcher@webrtc.org, Oct 16 2014

Labels: IceBox EngTriaged
Sorry, but this is a utility class that's not very high priority.  We'd welcome a patch to fix things, but otherwise we'll have to put this low on the priority list.
Project Member

Comment 7 by vikasmarwaha@webrtc.org, Oct 17 2014

Labels: -Mstone-38 Mstone-39
low prio. moving to M39 for now.
Project Member

Comment 8 by tnakamura@webrtc.org, Oct 21 2014

Labels: -Mstone-39
Clearing M39 label per comment #6.
Project Member

Comment 9 by tnakamura@webrtc.org, Nov 4 2015

Cc: -vikasmarwaha@webrtc.org
This bug hasn't been modified for more than a year. Is this still a valid open issue?
Project Member

Comment 10 by pthatcher@webrtc.org, Nov 8 2016

Labels: -Pri-2 Pri-3

Sign in to add a comment