Hey -
I've noticed that when I send an empty header value to the parser, the parser will consume the CRLF as whitespace and take the next header's key as a value,
for example, let's say this is our header section :
content-type: application/xml\r\n
host: example.com\r\n
empty: \r\n
empty2:....
When parsing the "empty" header - it will consume the CRLF as whitespace and continue to the next line until it sees "empty2" which will be taken.
This leads to more bugs, another one that I encountered as a result of that is that if there is an odd number of empty headers in the end of the header section - empty body will not get parsed correctly (also, didn't check - but if there is a body it might be counted as header value, not sure about that though)
According to the RFC, it is legitimate to have an empty field as a header value - https://datatracker.ietf.org/doc/html/rfc7230#section-3.2
Also - there are applications that actually require you to have those empty values - like WOPI
Hey -
I've noticed that when I send an empty header value to the parser, the parser will consume the CRLF as whitespace and take the next header's key as a value,
for example, let's say this is our header section :
When parsing the "empty" header - it will consume the CRLF as whitespace and continue to the next line until it sees "empty2" which will be taken.
This leads to more bugs, another one that I encountered as a result of that is that if there is an odd number of empty headers in the end of the header section - empty body will not get parsed correctly (also, didn't check - but if there is a body it might be counted as header value, not sure about that though)
According to the RFC, it is legitimate to have an empty field as a header value - https://datatracker.ietf.org/doc/html/rfc7230#section-3.2
Also - there are applications that actually require you to have those empty values - like WOPI