Closed Bug 12415 Opened 21 years ago Closed 20 years ago
nulls occasionally appear in the input stream provided by necko
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.
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.
Added assertion. To reproduce the problem load http://www.limdep.com/main.htm . Assigning bug to firstname.lastname@example.org
*** 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.
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? http://www.maths.newcastle.edu.au looks ok in 1999111508 build.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
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. ***
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
If you've updated the parser, then this is fixed.
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?
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.