Repository navigation
fix(httpv2,ospf): make silently pads or truncates fixed-width inputs #1251
Description
Describe the bug
HTTP/2 PING data is BytesField(length=8) (pcapkit/protocols/schema/application/httpv2.py:388) and OSPF auth_data is BytesField(length=8) (pcapkit/protocols/schema/application/ospf.py:39). A shorter input is zero-padded and a longer one is cut, so the packet no longer matches what the caller passed and info is not what was given.
To Reproduce
bytes(HTTP(type=Frame.PING, sid=0, frame={'opaque_data': b'abc'}))[9:] == b'abc\0\0\0\0\0'; 10 octetsb'0123456789'becomeb'01234567'.bytes(OSPF(auth_data=b'abc'))[16:24]isabcplus five zero octets; 10 octets are cut to 8.
Expected behavior
A wrong-width input raises ProtocolError rather than being resized without notice.
Found by the application round-trip audit (#1202). The repro was re-checked by an independent verifier, and I re-ran it on main at 11ae68ebf.
Activity
JarryShaw commentedon Oct 7, 2026
A worker is on it now.
fix(ospf,ngap): keep the parsed OSPF Packet Length and refuse octets …
fix(httpv2): HTTP/2 frames lose octets on rebuild (#1242-#1248, #1251)
fix(ospf,ngap): keep the parsed OSPF Packet Length and refuse octets …
fix(httpv2): HTTP/2 frames lose octets on rebuild (#1242-#1248, #1251) (
JarryShaw commentedon Oct 7, 2026
The HTTP/2 PING half is fixed by #1341, which has merged. A worker is now checking whether the OSPF half still reproduces on
mainafter #1304. It will fix it if it does, or close this issue with the measurement if it doesn't.JarryShaw commentedon Oct 7, 2026
I checked the OSPF half myself rather than dispatching a worker, and it is already fixed on
main(36db4220a).OSPF(auth_data=b'abc')andOSPF(auth_data=b'0123456789')both raiseProtocolError: OSPF: authentication data must be 8 octets. The PING half was fixed by #1341, so both halves are done and I am closing this issue.