Closed
Bug 72383
Opened 24 years ago
Closed 23 years ago
nsIHTTPChannel::IsPending() stopped working (was OK in 0.8).
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: galfandary, Assigned: darin.moz)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Also, it would be helpful if the implementation of nsIInputStream::Available()
for a stream from nsIChannel::Open() would return an error if there is no more
data to read and the underlying nsIHTTPChannel is done (!IsPending()),
thus a call to IsPending() won't be necessary if all I want is to know that
the stream has ended.
Reporter | ||
Comment 1•24 years ago
|
||
I propose the following fix to the problem:
nsresult
nsHTTPPipelinedRequest::IsPending(PRBool *result)
{
nsresult rv = NS_OK;
if (mCurrentReadRequest)
rv = mCurrentReadRequest->IsPending(result);
else
*result = mTransport ? PR_TRUE : PR_FALSE;
return rv;
}
NB: actually, isn't the existence of mTransport by itself
evidence enough that the request is pending?
Comment 2•24 years ago
|
||
I believe that there were some pretty big changes in this area, Comments for
changes to
http://lxr.mozilla.org/mozilla/source/netwerk/protocol/http/src/nsHTTPChannel.cpp
valeski@netscape.com Mar 12 18:00 sr=rpotts, r=gagan. 70743 . switching over to
new extensible URI::SchemeIs() api. and changing existing implementations over
to new api. also modified nsHTTP and nsHTTPS handlers a bit to make things cleaner.
Setting bug status to New and dding Valeski to the bug. I'm not a develper but
my queries for ansIHTTPChannel::IsPending() in LXR turned up nothing and looking
over recent changes to nsHTTPChannel.cpp, that API change comment caught my eye.
You might find information on this change discussed in
netscape.public.mozilla.netlib
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
I'd be really suprised if my schemeIs() changes caused this.
Assignee | ||
Comment 4•24 years ago
|
||
IsPending() comes from nsIRequest, which nsHTTPChannel implements. This sounds
like a problem with nsSocketTransport's nsSocketReadRequest::IsPending method.
Assignee | ||
Comment 5•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Reporter | ||
Comment 6•24 years ago
|
||
The problem is that mCurrentReadRequest == NULL up until
nsHTTPPipelinedRequest::OnStopRequest() is called. Thus the wrong
return value during this time is not caused by mCurrentReadRequest
but is simply the default in its absence. This default is wrong
and as I mentioned above replacing it with:
*result = mTransport ? PR_TRUE : PR_FALSE;
fixes the problem.
Assignee | ||
Comment 7•24 years ago
|
||
Guy: that's not even enough. IsPending() should return TRUE between the
time that AsyncOpen and OnStopRequest are called. Otherwise, it should
return FALSE. My patch to the socket transport is still needed, but you
are right... it doesn't solve this problem.
A pipelined request does not necessarily exist before AsyncOpen returns to
its caller. So, IsPending() would return FALSE if tested right after calling
AsyncOpen. I think we just need a flag on nsHTTPRequest.
Assignee | ||
Comment 8•24 years ago
|
||
kicking back to 0.9.1
Keywords: regression
Target Milestone: mozilla0.9 → mozilla0.9.1
Assignee | ||
Comment 9•24 years ago
|
||
my changes for bug 76866 will fix this bug as well.
Depends on: 76866
Assignee | ||
Comment 10•23 years ago
|
||
fixed with http branch landing
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 11•23 years ago
|
||
Guy Alfandary, is this problem fixed for you now?
Comment 12•22 years ago
|
||
Verified. Reporter, reopen if there is still a problem.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in
before you can comment on or make changes to this bug.
Description
•