#335 closed defect (fixed)
Leading null bytes received in HTTP Server
| Reported by: | zzz | Owned by: | zzz |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.9.19 |
| Component: | apps/i2ptunnel | Version: | 0.6.31 |
| Keywords: | Cc: | ||
| Parent Tickets: | Sensitive: | no |
Description
Connections sometimes start with a spurious single zero byte, and more rarely, more than one zero bytes.
Discovered in 0.6.1.9 in early 2006; workaround implemented by jrandom in 0.6.1.10. Still happening today as seen in the i2ptunnel.httpNullWorkaround stat. Unknown if the cause is on the client or server side, or if it is specific to HTTP or is in the I2CP or streaming layer. If the bug is not in the HTTP client-to-server direction, but is more general, then the workaround is not completely effective and it is a major bug.
Subtickets
Change History (9)
comment:1 Changed 10 years ago by
comment:2 Changed 9 years ago by
Been testing via Robert for weeks, and not seen this happen yet. I'm fairly certain that you can rule out streaminglib. The test will be part of the next beta release (in a short while from this post time) and will be incorporated into the next stable version. With many acting as testers, we'll get a report if the event happens.
comment:3 Changed 9 years ago by
| Owner: | set to zzz |
|---|---|
| Status: | new → accepted |
comment:4 Changed 8 years ago by
10 months, and not a single report of Robert spilling out the message, so, not streaming lib. That leaves the server and proxy sides.
comment:5 Changed 8 years ago by
| Milestone: | 0.8.12 → 0.8.14 |
|---|
comment:7 Changed 5 years ago by
| Milestone: | → 0.9.19 |
|---|---|
| Status: | accepted → testing |
Possible fix in 064616c2027d7a6aff3bcefea141ac580cafea37 0.9.18-17-rc
comment:8 Changed 5 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | testing → closed |
no nulls seen after several hours, declaring fixed.
comment:9 Changed 5 years ago by
No errors seen after 4 days on a server that previously saw ~2 per hour. Removing workaround and stat in 77405a1f959e22f986ea38239259c6628e888131 i2p.i2p.zzz.test2 to be propped for 0.9.20.
Interesting bug. I gladly can beat to death the streaming lib and see if it happens there via BOB and post a new comment. That will at least rule out streaming lib as a problem. I've never seen this happen in a BOB created tunnel, so I don't believe it's in the streaming lib, but I'll verify it for you anyway.