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 18 users
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
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
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