Closed Bug 12415 Opened 21 years ago Closed 20 years ago

nulls occasionally appear in the input stream provided by necko


(Core :: Networking, defect, P3)

Windows NT





(Reporter: rickg, Assigned: rpotts)




When loading Travelocity, we discovered that the occasional null char finds its
way into the buffer provided by Necko. Brendan suggests that you were unaware of
this problem, so I'm reporting it now. Harish added code the parsing engine to
detect that case and correct for it. That code should make a useful breakpoint
for you in your tests.
Target Milestone: M10
Assignee: gagan → rpotts
Assignee: rpotts → harishd
Target Milestone: M10 → M14
This isn't something we have to fix for m10. Eventually we should take the code
out of the parser that removes the nulls and replace it with an assertion. Then
when we hit it, we can figure out whether this is something coming from the
server, or a necko bug.

I want to reassign this to Harish to add the assertion and see if we can
reproduce the problem.
Assignee: harishd → warren
Added assertion.  To reproduce the problem load .

Assigning bug to
*** Bug 6644 has been marked as a duplicate of this bug. ***
Paulmac, I'm rubber-stamping 6644 as a duplicate. When you verify this bug, I'd
encourage you to give 6644 a quick look, as well.
Assignee: warren → rpotts
Rick is looking at this, although he told me that it looks like the server is
getting the content-length wrong. The null(s) are always at the very end.

My recommendation is to make the parser put a "funny bullet" character in the
document as it's displayed so that the content producer becomes aware of it and
can fix their bug. Another alternative might be to treat them as spaces.

Rick is investigating why netlib didn't seem to exhibit this problem.
*** Bug 16288 has been marked as a duplicate of this bug. ***
*** Bug 17600 has been marked as a duplicate of this bug. ***
Is this bug fixed now? looks ok in
1999111508 build.
Bulk move of all Necko (to be deleted component) bugs to new Networking

Moving Rick's M14 bugs to M13 (since he won't be here for M14). He can triage
them to M15 as appropriate.
What I know about this: For the cases we were seeing, the server was lying
about the content length, and saying it was one longer than it really was. This
caused an extra null to be served up to the parser. I think the parser should
just deal with this case, either putting in a bullet character or something, or
ignoring it.
Assignee: rpotts → rickg
*** Bug 20755 has been marked as a duplicate of this bug. ***
Assignee: rickg → rpotts
I'm putting this back into RickP's bug list (since it's already marked as a
duplicate of 20755). I've updated the parsing engine to deal with this case as
well -- so that embedded NULLs no longer cause us grief.
Closed: 20 years ago
Resolution: --- → FIXED
If you've updated the parser, then this is fixed.
QA Contact: paulmac → tever
giving to tever to verify hopefully
The code for this bug has not been checked in as of 1/21/2000, is it still a 
targeted for M13?
You need to log in before you can comment on or make changes to this bug.